Hello I've spent a few days trying to install all the packages required to use HaskellDB with either MySQL or SQlite3 (the only 2 DB the host I was thinking about is supporting) Well, I am giving up ! I seriously regret replacing ghc-6.6 with ghc-6.8, I didn't expect that building packages would be so ... unsucessfull and time-wasting. I just thought I'd let you know what's in store for "PHP-style-users- like-me" who want to use a database with ghc-6.8.1 at the moment, the hurdle is high ! I hope these packages will be fixed soon (I can't figure how to fix them myself obviously). And now I'm going to stay away from my computer for a while :) cheerio M
emmanuel.delaborde:
Hello
I've spent a few days trying to install all the packages required to use HaskellDB with either MySQL or SQlite3 (the only 2 DB the host I was thinking about is supporting)
Well, I am giving up ! I seriously regret replacing ghc-6.6 with ghc-6.8, I didn't expect that building packages would be so ... unsucessfull and time-wasting.
I just thought I'd let you know what's in store for "PHP-style-users- like-me" who want to use a database with ghc-6.8.1 at the moment, the hurdle is high !
I hope these packages will be fixed soon (I can't figure how to fix them myself obviously).
And now I'm going to stay away from my computer for a while :)
It was HaskellDB in particular that you tried? If so, please report this to the maintainer. And it reminds me to release the galois sqlite3 bindings, which do happily work with 6.8. Surely one of the other 15 haskell db bindings would also work. -- Don
Don Stewart
And it reminds me to release the galois sqlite3 bindings, which do happily work with 6.8. Surely one of the other 15 haskell db bindings would also work.
I think this is the problem, not the solution. There is a lot of DB libraries, just like there are a multitude of XML libraries, several collections, etc. Too many libraries are written as research projects or by grad students, and left to rot after release. The fragmentation also means that few libraries see any extensive testing - I was a bit surprised that apparently none of the XML libraries can handle files larger than a few megabytes, for instance. You're probably right that one of them would work, but especially new users will have no way of knowing which one. Only after the user has given up do people post similar experiences. This is getting better, of course - hackage will grow usage and activity statistics and perhaps ratings, the wiki will be extended with recommendations, more people will get involved in development. But at the moment, this is a problem. -k -- If I haven't seen further, it is by standing in the footprints of giants
On Nov 29, 2007, at 10:49 AM, Ketil Malde wrote:
I think this is the problem, not the solution. There is a lot of DB libraries, just like there are a multitude of XML libraries, several collections, etc. Too many libraries are written as research projects or by grad students, and left to rot after release. The fragmentation also means that few libraries see any extensive testing - I was a bit surprised that apparently none of the XML libraries can handle files larger than a few megabytes, for instance.
Hello My post wasn't intended as raging criticism, I can guess that developping these libraries takes a lot of (unpaid) work. And I am grateful for these libraries no matter what. However, if what is needed to install and use MySQL (or another popular DB) from Haskell could be drastically made shorter and easier, more people might use Haskell in domains where it still is largely marginal (like say... websites). Manu
Ketil Malde wrote:
I think this is the problem, not the solution. There is a lot of DB libraries, just like there are a multitude of XML libraries, several collections, etc. Too many libraries are written as research projects or by grad students, and left to rot after release. The fragmentation also means that few libraries see any extensive testing - I was a bit surprised that apparently none of the XML libraries can handle files larger than a few megabytes, for instance.
You're probably right that one of them would work, but especially new users will have no way of knowing which one. Only after the user has given up do people post similar experiences.
This is getting better, of course - hackage will grow usage and activity statistics and perhaps ratings, the wiki will be extended with recommendations, more people will get involved in development. But at the moment, this is a problem.
This is one of the more frustrating aspects of Haskell. It's not that nobody has written DB bindings - they most certainly have. It's not that nobody has written compression or cryptography bindings - they have. It's that there is a small zoo of them, and it's really hard to pick out which ones are the "good" ones. I really hope this does improve in time. (And I really wish I could do something positive to make this happen...)
andrewcoppin:
Ketil Malde wrote:
I think this is the problem, not the solution. There is a lot of DB libraries, just like there are a multitude of XML libraries, several collections, etc. Too many libraries are written as research projects or by grad students, and left to rot after release. The fragmentation also means that few libraries see any extensive testing - I was a bit surprised that apparently none of the XML libraries can handle files larger than a few megabytes, for instance.
You're probably right that one of them would work, but especially new users will have no way of knowing which one. Only after the user has given up do people post similar experiences.
This is getting better, of course - hackage will grow usage and activity statistics and perhaps ratings, the wiki will be extended with recommendations, more people will get involved in development. But at the moment, this is a problem.
This is one of the more frustrating aspects of Haskell. It's not that nobody has written DB bindings - they most certainly have. It's not that nobody has written compression or cryptography bindings - they have. It's that there is a small zoo of them, and it's really hard to pick out which ones are the "good" ones. I really hope this does improve in time. (And I really wish I could do something positive to make this happen...)
We have the start on a solution for how to pick "the good ones". * Go to Hackage * Click on the 'experimental search interface' http://hackage.haskell.org/packages/search.html * Click on 'advanced search': http://hackage.haskell.org/packages/advancedsearch.html * Type the name of the library you're interested in, into the "required-by" field. We'll consider which binary IO library is most popular, from: * binary * NewBinary * safecopy The search engine returns the results: * binary, is used by 12 other packages: bencode, Etherbunny,GrowlNotify, harchive hmp3, hpaste, HPDF, infinity safecopy, tar, torrent, htar * NewBinary, is used by 4 other packages: ASN1, Crypto, GrowlNotify, Hmpf * safecopy, is used by 0 packages. So choose Data.Binary if you trust the wisdom of the crowd. So as a crude heuristic for measuring what the masses are saying, this seems reasonable. -- Don
Hi
We have the start on a solution for how to pick "the good ones".
We'll consider which binary IO library is most popular, from: The search engine returns the results:
* binary, is used by 12 other packages:
This only works with libraries that are lower-level, like binary, which other libraries are likely to use. For libraries such as HTML/XML parsing, its likely that the majority of users are applications, which are under-represented on hackage. I don't know what safecopy does, but I'm guessing its a wrapper around binary providing some functionality, so it follows that more people probably use the lower-level library than safecopy. Thanks Neil
Don Stewart wrote:
We have the start on a solution for how to pick "the good ones".
* Go to Hackage * Click on the 'experimental search interface' http://hackage.haskell.org/packages/search.html * Click on 'advanced search': http://hackage.haskell.org/packages/advancedsearch.html * Type the name of the library you're interested in, into the "required-by" field.
So as a crude heuristic for measuring what the masses are saying, this seems reasonable.
From where I'm sitting, the main problems with Haskell packages are thus: 1. For certain tasks, there are multiple possible packages, and it's not really clear which one to go for. Having more than one choice is good. (E.g., there's Gtk2hs and there's wxHaskell, and you pick the one you want based on personal preference.) Having *dozens* of different packages for the same task, some more complete than others, some more maintained than others, etc., is just confusing. 2. Most things on Hackage don't seem to want to work on Windows. (Evidently this is being worked on. Stream Fusion installed just fine with a little help from Duncan...) 3. It's not easy to tell from the package summary whether it does what you want. (It looks like this too is being worked on with automatic generation of Haddoc information, which should help. Assuming there's any Haddoc comments to display, that is...) 4. General package quality. Some are excellent, some aren't. Given time, hopefully the excellent ones will rise to the top, and the less good ones will improve or dissappear. So it looks like this one is just a question of time and effort. Hopefully this will also somewhat solve #1 eventually... Just my opinion - others are welcomed to dissagree. ;-)
Hi
1. For certain tasks, there are multiple possible packages, and it's not really clear which one to go for. Having more than one choice is good. (E.g., there's Gtk2hs and there's wxHaskell, and you pick the one you want based on personal preference.) Having *dozens* of different packages for the same task, some more complete than others, some more maintained than others, etc., is just confusing. + points 3 and 4
This can be solved easily using blogs. If you use a package successfully, blog about it. Write about how great it was, or what was lacking. Say what problems you ran into. Perhaps write a slightly tutorialish post saying what you used it for and a snippet of code. If a few people do this, Google will do the rest with search results.
2. Most things on Hackage don't seem to want to work on Windows. (Evidently this is being worked on. Stream Fusion installed just fine with a little help from Duncan...)
Windows, the unloved Haskell platform... Not much you can do about this, short of breaking into peoples houses and reformatting their hard drive. I know most authors would be happy to accept a patch fixing whatever issue there is - so all it needs is more Windows users. Perhaps a wiki page listing the common mistakes a Linux user can make to render their package non-working on Windows? Thanks Neil
Hello Neil, Friday, November 30, 2007, 1:32:25 AM, you wrote:
1. For certain tasks, there are multiple possible packages, and it's not really clear which one to go for. Having more than one choice is good.
This can be solved easily using blogs. If you use a package
user comments system on hackage may be better -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Neil,
Friday, November 30, 2007, 1:32:25 AM, you wrote:
1. For certain tasks, there are multiple possible packages, and it's not really clear which one to go for. Having more than one choice is good.
This can be solved easily using blogs. If you use a package
user comments system on hackage may be better
I agree. Keep the information all in one place. (And what's more, one place where the library author is likely to see it too.)
Hello Andrew, Thursday, November 29, 2007, 11:51:32 PM, you wrote:
This is one of the more frustrating aspects of Haskell. It's not that nobody has written DB bindings - they most certainly have. It's not that nobody has written compression or cryptography bindings - they have. It's that there is a small zoo of them, and it's really hard to pick out which ones are the "good" ones. I really hope this does improve in time. (And I really wish I could do something positive to make this happen...)
when i come to using ftp/http in my program, i wrote binding to wininet.dll in two days. this may be not reasonable for occasional scriptiong but at least works for larger apps -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Andrew,
Thursday, November 29, 2007, 11:51:32 PM, you wrote:
This is one of the more frustrating aspects of Haskell. It's not that nobody has written DB bindings - they most certainly have. It's not that nobody has written compression or cryptography bindings - they have. It's that there is a small zoo of them, and it's really hard to pick out which ones are the "good" ones. I really hope this does improve in time. (And I really wish I could do something positive to make this happen...)
when i come to using ftp/http in my program, i wrote binding to wininet.dll in two days. this may be not reasonable for occasional scriptiong but at least works for larger apps
I don't know C, so I can't write bindings to anything...
On Nov 28, 2007 1:11 PM, manu
Hello
I've spent a few days trying to install all the packages required to use HaskellDB with either MySQL or SQlite3 (the only 2 DB the host I was thinking about is supporting)
Well, I am giving up ! I seriously regret replacing ghc-6.6 with ghc-6.8, I didn't expect that building packages would be so ... unsucessfull and time-wasting.
I just thought I'd let you know what's in store for "PHP-style-users- like-me" who want to use a database with ghc-6.8.1 at the moment, the hurdle is high !
I hope these packages will be fixed soon (I can't figure how to fix them myself obviously).
And now I'm going to stay away from my computer for a while :)
cheerio
M
Hi Manu, I built HSQL MySQL on Windows using GHC-6.8.1. I had to replace the Setup.lhs file be able to build with Cabal-1.2.2.0 (I found a working one on the web) and had to modify the cabal file (build-depends list). If you're interested I attached a copy of the two files. HSQL also comes with a SQLite module but I didn't tried it. The problems I encountered when compiling using GHC 6.8.1 are almost always the same and are very well described in this document: http://haskell.org/haskellwiki/Upgrading_packages. Usually you just have to adapt the build-depends list and change the imports of Data.ByteString.Base which was split in Internal and Usafe. It sometimes requires some try/error iterations. Using this information I was able to build many modules on Win32 / GHC 6.8.1without problems (HTTP, HaXmL, polyparse, exif, gtk2hs, hxt, regex-pcre, compact-string). It can be more complicated when the package do not use a simple build script (as was the case for HSQL). Best regards, Olivier.
On Nov 28, 2007 10:11 AM, manu
Hello
I've spent a few days trying to install all the packages required to use HaskellDB with either MySQL or SQlite3 (the only 2 DB the host I was thinking about is supporting)
I'm not surprised you had this much trouble. If you are also building on Windows, prepare to be extremely persistent. That said, you should really look at the HDBC bindings, rather than haskelldb. haskelldb looks awesome but when you see the queries it produces you will cry. The first problem is "DISTINCT" is added to all queries. It's also unable to do joins. Finally, it's not really actively maintained. HDBC, on the other hand, compiles OK on Windows (once you figure out some tricky bits) and presumably works excellent on *nix. You may have a lot more luck there. Don't feel too bad - you aren't the first to have this experience and certainly not the last. If you want to give back, write up what you learned (or didn't learn) on the wiki: www.haskell.org. Justin
On Wed, 2007-11-28 at 19:11 +0100, manu wrote:
Hello
I've spent a few days trying to install all the packages required to use HaskellDB with either MySQL or SQlite3 (the only 2 DB the host I was thinking about is supporting)
Well, I am giving up ! I seriously regret replacing ghc-6.6 with ghc-6.8, I didn't expect that building packages would be so ... unsucessfull and time-wasting.
Yes, you were unlucky in that you jumped in just after ghc 6.8.1 was released and before 90% of the packages on hackage had been updated to work with 6.8 yet. In the mean time you would indeed be better off with 6.6. Our hackage infrastructure is still fairly immature and lacks any mechanism for indicating which packages work on which platforms. I agree it's frustrating. Then additionally there is the complication that many packages that use C libs (like DB client libs) just don't build out of the box on windows because the development files are not installed. Probably the best eventual solution for Windows is to build infrastructure to make binary packages for Windows. People are working on that. Duncan
participants (9)
-
Andrew Coppin -
Bulat Ziganshin -
Don Stewart -
Duncan Coutts -
Justin Bailey -
Ketil Malde -
manu -
Neil Mitchell -
Olivier Boudry