Type problem with simple takusen code (was: Trivial database access in Haskell)

(Wow, it looks like my message has generated quite a bit of traffic!
Thanks, guys!)
On 12/11/06, Taral
The magic commands are:
runhaskell Setup.lhs configure runhaskell Setup.lhs build runhaskell Setup.lhs install
Excellent! Now I'm getting somewhere. I even found the sample code in the takusen documentation. I'm trying to modify the sample code to work with a local database I have, and I'm getting some type errors which mean nothing much to me. The code I have, stored in a file called db.hs and run via "runhaskell db.hs" is: import Control.Monad.Trans import Database.Oracle.Enumerator import Database.Enumerator query1Iteratee :: (Monad m) => String -> IterAct m [String] query1Iteratee a accum = result' (a:accum) main :: IO () main = do withSession (connect "USER" "PASSWORD" "DB") $ do -- simple query, returning reversed list of rows. r <- doQuery (sql "select username from all_users") query1Iteratee [] liftIO $ putStrLn $ show r The error I'm getting is db.hs:10:64: Couldn't match expected type `forall mark. DBM mark Session a' against inferred type `a1 b' In the second argument of `($)', namely `do r <- doQuery (sql "select username from all_users") query1Iteratee [] liftIO $ (putStrLn $ (show r))' In the expression: (withSession (connect "USER" "PASSWORD" "DB")) $ (do r <- doQuery (sql "select username from all_users") query1Iteratee [] liftIO $ (putStrLn $ (show r))) In the expression: do (withSession (connect "USER" "PASSWORD" "DB")) $ (do r <- doQuery (sql "select username from all_users") query1Iteratee [] liftIO $ (putStrLn $ (show r))) I'm not sure what might be wrong here - or even, for that matter, how to diagnose the problem. To complicate the matter, it's possible that I'm getting a database connection error which I've not got code in to report. (I've no easy way to test that the database connection from Haskell is working, or rather *this* is the easy way :-)) Can anyone offer any pointers? (I take the suggestions about asking on IRC, but I can't get at IRC from here due to firewall issues, so I'll have to stick to email). Paul.

Paul Moore wrote:
db.hs:10:64: Couldn't match expected type `forall mark. DBM mark Session a' against inferred type `a1 b' In the second argument of `($)', namely `do r <- doQuery (sql "select username from all_users") query1Iteratee [] liftIO $ (putStrLn $ (show r))' In the expression: (withSession (connect "USER" "PASSWORD" "DB")) $ (do r <- doQuery (sql "select username from all_users") query1Iteratee [] liftIO $ (putStrLn $ (show r))) In the expression: do (withSession (connect "USER" "PASSWORD" "DB")) $ (do r <- doQuery (sql "select username from all_users") query1Iteratee [] liftIO $ (putStrLn $ (show r)))
I had the same problem... ($) doesn't have the expected semantics with existential types (like "forall mark. DBM mark Session a"). Some day I will be able to explain why this is so, but in the meantime, if you replace "liftIO $ putStrLn $ show r" with "liftIO (putStrLn (show r))", it should work.

main :: IO () main = do withSession (connect "USER" "PASSWORD" "DB") $ do -- simple query, returning reversed list of rows. r <- doQuery (sql "select username from all_users") query1Iteratee [] liftIO $ putStrLn $ show r
The error I'm getting is
db.hs:10:64: Couldn't match expected type `forall mark. DBM mark Session a' against inferred type `a1 b' In the second argument of `($)', namely `do r <- doQuery (sql "select username from all_users") ...
This is a fault in the example. Try this:
-- ($) replaced here with () withSession (connect "USER" "PASSWORD" "DB") ( do r <- doQuery (sql ... liftIO $ putStrLn $ show r --- here should be OK )
($) doesn't handle higher-ranked types, and overusing it can lead to these kinds of errors. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

On 12/12/06, Bayley, Alistair
($) doesn't handle higher-ranked types, and overusing it can lead to these kinds of errors.
Thanks - not something I'd have ever found on my own. Next one:
runhaskell db.hs can't load .so/.DLL for: sqlite3 (addDLL: unknown error)
This seems odd, as I'm not (intending to be) using sqlite here. If I copy a sqlite3.dll onto my PATH (just to get by, it's quite possible sqlite isn't set up right but I really don't care just now) I get past this, but get
runhaskell db.hs <interactive>: C:\Program Files\Haskell\Takusen-0.6\ghc-6.6/HSTakusen-0.6.o: unknown symbol `_PQconnectdb' ghc.exe: unable to load package `Takusen-0.6'
No chance here - I don't have any sort of PostgreSQL software around. I've no idea how it might have thought I did. Can I somehow force PostgreSQL to be disabled? If I need to rebuild to do so (grumble) then how do I uninstall the current version of takusen (it's not in "Add/Remove programs" and "runhaskell Setup.hs" doesn't seem to offer an uninstall option... Thanks again, Paul.

On 12/12/06, Paul Moore
Can I somehow force PostgreSQL to be disabled? If I need to rebuild to do so (grumble) then how do I uninstall the current version of takusen (it's not in "Add/Remove programs" and "runhaskell Setup.hs" doesn't seem to offer an uninstall option...
There should be a README or INSTALL file in the original tarball that
explains how to do that. I suspect it is a flag you have to pass to
"runhaskell Setup.lhs configure".
--
Taral

On 12/12/06, Taral
On 12/12/06, Paul Moore
wrote: Can I somehow force PostgreSQL to be disabled? If I need to rebuild to do so (grumble) then how do I uninstall the current version of takusen (it's not in "Add/Remove programs" and "runhaskell Setup.hs" doesn't seem to offer an uninstall option...
There should be a README or INSTALL file in the original tarball that explains how to do that. I suspect it is a flag you have to pass to "runhaskell Setup.lhs configure".
Should be, but isn't, unfortunately. The Setup.hs file includes some code defining configPG etc, but there's nothing I can see for the user control how it works. Maybe something in the cabal infrastructure handles this, but I've not had time yet to dive into the cabal documentation on the hope of finding something. Paul.

From: Paul Moore [mailto:p.f.moore@gmail.com]
runhaskell db.hs can't load .so/.DLL for: sqlite3 (addDLL: unknown error)
This seems odd, as I'm not (intending to be) using sqlite here. If I copy a sqlite3.dll onto my PATH (just to get by, it's quite possible sqlite isn't set up right but I really don't care just now) I get past this, but get
runhaskell db.hs <interactive>: C:\Program Files\Haskell\Takusen-0.6\ghc-6.6/HSTakusen-0.6.o: unknown symbol `_PQconnectdb' ghc.exe: unable to load package `Takusen-0.6'
This appears to be caused by ghci/runhaskell wanting to link the entire library at once, rather than just the modules you're using. I don't know if this is a bug or a feaure with ghci; anybody else want to comment? This problem affects both ghci and runhaskell. It does not affect ghc, though. I'm not sure what the best solution is; we might have to do what Krasimir did with HSQL and make each database-specific module a separate package. For now, if you want to use Takusen, you are stuck with ghc (the compiler). This invocation:
ghc --make db.hs -o db should make you a working db.exe.
I have added a README.txt to the darcs repo, which hopefully provides a lot of this missing information. I haven't added uninstall instructions though :-) Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

On 12/13/06, Bayley, Alistair
From: Paul Moore [mailto:p.f.moore@gmail.com] This appears to be caused by ghci/runhaskell wanting to link the entire library at once, rather than just the modules you're using. I don't know if this is a bug or a feaure with ghci; anybody else want to comment?
This problem affects both ghci and runhaskell. It does not affect ghc, though. I'm not sure what the best solution is; we might have to do what Krasimir did with HSQL and make each database-specific module a separate package.
For now, if you want to use Takusen, you are stuck with ghc (the compiler). This invocation:
ghc --make db.hs -o db should make you a working db.exe.
Thanks for the explanation - it's no problem using ghc, I was only using runhaskell for (a tiny bit of) convenience. Having said that, I now get
ghc --make db.hs -o db [1 of 1] Compiling Main ( db.hs, db.o ) Linking db.exe ... D:\Apps\GHC\gcc-lib\ld.exe: cannot find -lsqlite3
collect2: ld returned 1 exit status
This may be because I have a sqlite3.dll in my PATH, but no development libs. Would that make configure think that sqlite is available, but because the build needs the link library, fail at that stage? If so, I may well be heading for a problem with Oracle, as I have the client only installed, so the OCI DLLs are present, but not the headers and lib files. (I've hit this one before, and can get round it, though). I had a look on the sqlite website, but can't find a "development libraries" download. I'm reluctant to get bogged down in building sqlite, so I'm leaving it there for now. To work around this, I removed sqlite3.exe from my PATH, and set up an oracle directory in my PATH which did include OCI. Then runhaskell Setup.hs configure reported no sqlite, no postgres, and Oracle from where I wanted. I reinstalled Takusen with these options. However, now when I run ghc --make, I get a string of link errors from Oracle stuff (OCIconstants.o). This is serious progress - I'm linking the right stuff this time. I've seen similar issues before, where I tried to use gcc to link to the Oracle-supplied OCI libraries (or at least I think that was it), as Oracle supply MSVC compatible libraries instead. Could this be relevant here? I know ghc uses the gcc linker, so it seems like a possibility.
I have added a README.txt to the darcs repo, which hopefully provides a lot of this missing information. I haven't added uninstall instructions though :-)
That looks excellent - it would have given me exactly what I needed. Paul.

Having said that, I now get
ghc --make db.hs -o db [1 of 1] Compiling Main ( db.hs, db.o ) Linking db.exe ... D:\Apps\GHC\gcc-lib\ld.exe: cannot find -lsqlite3
collect2: ld returned 1 exit status
This may be because I have a sqlite3.dll in my PATH, but no development libs.
You need to have sqlite3.exe in the same folder as sqlite3.dll. sqlite3.exe is what the installer looks for - if it finds it, then it assumes sqlite3.dll is in the same place. When you built takusen, was this in your path? Check the output from "runhaskell Setup.hs configure": this tells you if it finds Sqlite, and if so where it is. This information is then baked into takusen.buildinfo, and that's what's used by ghc for linking when you build your program. You don't need it if you want to use Oracle: just remove it from your path and configure/build/install Takusen.
However, now when I run ghc --make, I get a string of link errors from Oracle stuff (OCIconstants.o). This is serious progress - I'm linking the right stuff this time. I've seen similar issues before, where I tried to use gcc to link to the Oracle-supplied OCI libraries (or at least I think that was it), as Oracle supply MSVC compatible libraries instead. Could this be relevant here? I know ghc uses the gcc linker, so it seems like a possibility.
Not a problem I've experienced, but then my Oracle client install includes the headers etc. I don't think these are necessary unless you compile -fvia-C, which I don't think is happening (ghc -O results in -fvia-C, though). I use ghc for compilation and linking, and I have no trouble. Can you send me the compiler/linker output? Perhaps best if we take this off-list. Also, what version of Oracle is it? I've developed against 8i, and haven't had a chance to test against later versions. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
participants (4)
-
Bayley, Alistair
-
Paul Moore
-
Seth Gordon
-
Taral