haskelldb-users

[Haskelldb-users] ghc 6.6.1 compilation

[Peter S. <si...@cr...>]

Hi,

I tried to build the current CVS head with GHC 6.6.1. To make
Cabal work, I had to change the extensions field as follows:

--- a/haskelldb.cabal
+++ b/haskelldb.cabal
@@ -7,7 +7,7 @@ License: BSD3
 build-depends: haskell98, base
 Extensions: ExistentialQuantification,
             OverlappingInstances,
-            AllowUndecidableInstances,
+            UndecidableInstances,
             MultiParamTypeClasses
 Synopsis: SQL unwrapper for Haskell.

During the build, however, I get this error:

src/Database/HaskellDB/Database.hs:116:16:
    The scoped type variables `ef' and `f'
      are bound to the same type (variable)
      Distinct scoped type variables must be distinct
    In the pattern: _ :: Rel (RecCons ef (Expr ea) er)
    In the definition of `getRec':
	getRec vfs (_ :: Rel (RecCons ef (Expr ea) er)) (f : fs) stmt
		 = do x <- getValue vfs stmt f
		      r <- getRec vfs (undefined :: Rel er) fs stmt
		      return ((RecCons x) . r)
    In the definition for method `getRec'

I'm not sure how to fix that. Can anyone help me, please?

Peter

Re: [Haskelldb-users] ghc 6.6.1 compilation

[Bjorn B. <bri...@cs...>]

On Sep 9, 2007, at 2:00 , Peter Simons wrote:

> Hi,
>
> I tried to build the current CVS head with GHC 6.6.1. To make
> Cabal work, I had to change the extensions field as follows:
>
> --- a/haskelldb.cabal
> +++ b/haskelldb.cabal
> @@ -7,7 +7,7 @@ License: BSD3
>  build-depends: haskell98, base
>  Extensions: ExistentialQuantification,
>              OverlappingInstances,
> -            AllowUndecidableInstances,
> +            UndecidableInstances,
>              MultiParamTypeClasses
>  Synopsis: SQL unwrapper for Haskell.
>
> During the build, however, I get this error:
>
> src/Database/HaskellDB/Database.hs:116:16:
>     The scoped type variables `ef' and `f'
>       are bound to the same type (variable)
>       Distinct scoped type variables must be distinct
>     In the pattern: _ :: Rel (RecCons ef (Expr ea) er)
>     In the definition of `getRec':
> 	getRec vfs (_ :: Rel (RecCons ef (Expr ea) er)) (f : fs) stmt
> 		 =3D do x <- getValue vfs stmt f
> 		      r <- getRec vfs (undefined :: Rel er) fs stmt
> 		      return ((RecCons x) . r)
>     In the definition for method `getRec'
>
> I'm not sure how to fix that. Can anyone help me, please?

You said "CVS head", if that's correct, use the darcs repo instead:

darcs get http://darcs.haskell.org/haskelldb/

The currect darcs version builds with GHC 6.6, I haven't tested 6.6.1 =20=

myself.

/Bj=F6rn

Re: [Haskelldb-users] ghc 6.6.1 compilation

[Peter S. <si...@cr...>]

 > darcs get http://darcs.haskell.org/haskelldb/

Thanks to everyone who responded; the latest darcs version does
work fine. It might be a good idea to empty the CVS repository at
sourceforge (or otherwise mark it as obsolete). I didn't realize
that it is no longer used. 

Best regards,
Peter

Re: [Haskelldb-users] ghc 6.6.1 compilation

[Bjorn B. <bri...@cs...>]

On Sep 10, 2007, at 21:07 , Peter Simons wrote:

>> darcs get http://darcs.haskell.org/haskelldb/
>
> Thanks to everyone who responded; the latest darcs version does
> work fine. It might be a good idea to empty the CVS repository at
> sourceforge (or otherwise mark it as obsolete). I didn't realize
> that it is no longer used.
>
> Best regards,
> Peter

That sounds like a good idea. I'm reluctant to delete it, but marking =20=

it as obsolete with a reference to the darcs version would be nice. =20
Does anyone know how to do something like darcs' motd? Or some other =20
way to mark a CVS repo as obsolete?

/Bj=F6rn

Re: [Haskelldb-users] ghc 6.6.1 compilation

[Peter S. <si...@cr...>]

Bjorn Bringert writes:

 > Does anyone know how to do something like darcs' motd? Or some
 > other way to mark a CVS repo as obsolete?

Maybe it's possible to have Sourceforge disable the CVS
repository?

Anyway, I'd like to say that HaskellDB is great. I was sceptical
at first because I thought that feeding plain text SQL queries
into HSQL would be good enough, but type-safe access really is a
different thing. Thanks a lot to everyone involved for providing
this fine library as free software,

Best regards,
Peter