ANN: HDBC v2.0 now available

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ANN: HDBC v2.0 now available

John Goerzen-3
Hi everyone,

I'm pleased to announce that HDBC v2.0 is now available.
Simultaneously, HDBC-sqlite3, HDBC-postgresql, and HDBC-odbc v2.0 have
also been uploaded.  All may be found from Hackage, or at
software.complete.org.

A guide to new features and migration can be found at:

  http://software.complete.org/software/wiki/hdbc/NewIn20

A partial summary of it follows:

New Features:

     * Pervasive Unicode support now part of the HDBC API and implemented
       by all backend drivers. Based on utf8-string and conversions
       between UTF-8 ByteStrings and Haskell Strings.

     * Full support for GHC 6.10 is new. Full support for GHC 6.8 is
       maintained.

     * Native support for the new exception handling in GHC 6.10, with CPP
       conditional compilation to continue supporting the old-style
       exceptions for users of GHC 6.8 or Hugs.

     * HDBC now has direct support for marshalling virtually all of the
       Data.Time.* types to and from SQL database date/time types. toSql
       and fromSql/safeFromSql now support conversions between Data.Time.*
       types and SqlValue. Conversions between System.Time.* types were
       present from the beginning and will remain. Automatic conversions
       are, of course, contingent on support in database engines and HDBC
       database backend drivers and may not be possible with all
       databases.

     * Major expansion of SqlValue to be able to carry date/time data
       to/from databases in terms of Data.Time.* types.

          + The old SqlTimeDiff and SqlEpochTime types continue to be
            present, but are deprecated and will be removed in a future.
            toSql no longer converts anything to them. The System.Time.*
            types are converted to the new Data.Time-based SqlValues. It
            should be exceptionally rare that any user code would use
            these types directly, but they are being retained in this
            version out of an abundance of caution.

     * Replace fromSql with safeFromSql, which returns Left on impossible
       conversions instead of raising an exception.

          + Wrote a new fromSql that behaves just like the old one, but is
            implemented in terms of safeFromSql. It converts the
            safeFromSql errors to exceptions.

          + The new structure made it possible to greatly enhance many
            error messages throughout the conversion process instances.

          + Removed SqlType typeclass. Re-implemented SqlValue conversions
            in terms of the generic infrastructure in the convertible
            package. Simplified code significantly due to this.

     * Lots of additional docs.

     * New skeleton test suite for HDBC itself (to be expanded upon
       later).

Richer Date and Time Support

   HDBC 1.x had only two ways of getting dates and times between Haskell
   and a database: an epoch (an Integer representing the number of seconds
   since midnight Jan 1 1970 UTC) and an Integer representing a TimeDiff
   (a count of elapsed time). While this approach could represent a
   precise instant in time, it was not always the most helpful. Most
   notably, you might sometimes want to load date information without
   time, time without date, or record what timezone the time was measured
   within. HDBC can now convert all of these things with much greater
   precision.

Thanks to Phil Wise for adding the first Unicode support (to
HDBC-postgresql originally) and to Alson Kemp for adding the first
advanced date/time marshalling support (also to HDBC-postgresql
originally).  The experience of adding these features to a single
backend driver first made clear a good way to add them to HDBC API
as a whole.

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Valentyn Kamyshenko
Hello John,

I'm trying to install the new version of HDBC on my Mac (ghc version  
is 6.10.1), and get the following error:

# cabal upgrade --global
Resolving dependencies...
'HDBC-2.0.0' is cached.
Configuring HDBC-2.0.0...
Preprocessing library HDBC-2.0.0...
Preprocessing executables for HDBC-2.0.0...
Building HDBC-2.0.0...
[1 of 7] Compiling Database.HDBC.SqlValue ( Database/HDBC/SqlValue.hs,  
dist/build/Database/HDBC/SqlValue.o )
[2 of 7] Compiling Database.HDBC.ColTypes ( Database/HDBC/ColTypes.hs,  
dist/build/Database/HDBC/ColTypes.o )
[3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/
Statement.hs, dist/build/Database/HDBC/Statement.o )

Database/HDBC/Statement.hs:113:9:
     Type constructor `Exception' used as a class
     In the instance declaration for `Exception SqlError'
cabal: Error: some packages failed to install:
HDBC-2.0.0 failed during the building phase. The exception was:
exit: ExitFailure 1

any suggestions?

Thanks you,

   Valentyn.

On Jan 30, 2009, at 1:28 PM, John Goerzen wrote:

> Hi everyone,
>
> I'm pleased to announce that HDBC v2.0 is now available.
> Simultaneously, HDBC-sqlite3, HDBC-postgresql, and HDBC-odbc v2.0 have
> also been uploaded.  All may be found from Hackage, or at
> software.complete.org.
>
> A guide to new features and migration can be found at:
>
>  http://software.complete.org/software/wiki/hdbc/NewIn20
>
> A partial summary of it follows:
>
> New Features:
>
>     * Pervasive Unicode support now part of the HDBC API and  
> implemented
>       by all backend drivers. Based on utf8-string and conversions
>       between UTF-8 ByteStrings and Haskell Strings.
>
>     * Full support for GHC 6.10 is new. Full support for GHC 6.8 is
>       maintained.
>
>     * Native support for the new exception handling in GHC 6.10,  
> with CPP
>       conditional compilation to continue supporting the old-style
>       exceptions for users of GHC 6.8 or Hugs.
>
>     * HDBC now has direct support for marshalling virtually all of the
>       Data.Time.* types to and from SQL database date/time types.  
> toSql
>       and fromSql/safeFromSql now support conversions between  
> Data.Time.*
>       types and SqlValue. Conversions between System.Time.* types were
>       present from the beginning and will remain. Automatic  
> conversions
>       are, of course, contingent on support in database engines and  
> HDBC
>       database backend drivers and may not be possible with all
>       databases.
>
>     * Major expansion of SqlValue to be able to carry date/time data
>       to/from databases in terms of Data.Time.* types.
>
>          + The old SqlTimeDiff and SqlEpochTime types continue to be
>            present, but are deprecated and will be removed in a  
> future.
>            toSql no longer converts anything to them. The  
> System.Time.*
>            types are converted to the new Data.Time-based SqlValues.  
> It
>            should be exceptionally rare that any user code would use
>            these types directly, but they are being retained in this
>            version out of an abundance of caution.
>
>     * Replace fromSql with safeFromSql, which returns Left on  
> impossible
>       conversions instead of raising an exception.
>
>          + Wrote a new fromSql that behaves just like the old one,  
> but is
>            implemented in terms of safeFromSql. It converts the
>            safeFromSql errors to exceptions.
>
>          + The new structure made it possible to greatly enhance many
>            error messages throughout the conversion process instances.
>
>          + Removed SqlType typeclass. Re-implemented SqlValue  
> conversions
>            in terms of the generic infrastructure in the convertible
>            package. Simplified code significantly due to this.
>
>     * Lots of additional docs.
>
>     * New skeleton test suite for HDBC itself (to be expanded upon
>       later).
>
> Richer Date and Time Support
>
>   HDBC 1.x had only two ways of getting dates and times between  
> Haskell
>   and a database: an epoch (an Integer representing the number of  
> seconds
>   since midnight Jan 1 1970 UTC) and an Integer representing a  
> TimeDiff
>   (a count of elapsed time). While this approach could represent a
>   precise instant in time, it was not always the most helpful. Most
>   notably, you might sometimes want to load date information without
>   time, time without date, or record what timezone the time was  
> measured
>   within. HDBC can now convert all of these things with much greater
>   precision.
>
> Thanks to Phil Wise for adding the first Unicode support (to
> HDBC-postgresql originally) and to Alson Kemp for adding the first
> advanced date/time marshalling support (also to HDBC-postgresql
> originally).  The experience of adding these features to a single
> backend driver first made clear a good way to add them to HDBC API
> as a whole.
>
> -- John
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Krzysztof Skrzętnicki
On Sat, Jan 31, 2009 at 00:07, Valentyn Kamyshenko <[hidden email]> wrote:
Hello John,

I'm trying to install the new version of HDBC on my Mac (ghc version is 6.10.1), and get the following error:

# cabal upgrade --global
Resolving dependencies...
'HDBC-2.0.0' is cached.
Configuring HDBC-2.0.0...
Preprocessing library HDBC-2.0.0...
Preprocessing executables for HDBC-2.0.0...
Building HDBC-2.0.0...
[1 of 7] Compiling Database.HDBC.SqlValue ( Database/HDBC/SqlValue.hs, dist/build/Database/HDBC/SqlValue.o )
[2 of 7] Compiling Database.HDBC.ColTypes ( Database/HDBC/ColTypes.hs, dist/build/Database/HDBC/ColTypes.o )
[3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/Statement.hs, dist/build/Database/HDBC/Statement.o )

Database/HDBC/Statement.hs:113:9:
   Type constructor `Exception' used as a class
   In the instance declaration for `Exception SqlError'
cabal: Error: some packages failed to install:
HDBC-2.0.0 failed during the building phase. The exception was:
exit: ExitFailure 1

I got the same error: Windows XP, GHC 6.10.1.
For some reason imported Control.Exception module appears to be 6.8.* version.

All best

Christopher Skrzętnicki
 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Michael Snoyman


2009/1/30 Krzysztof Skrzętnicki <[hidden email]>
On Sat, Jan 31, 2009 at 00:07, Valentyn Kamyshenko <[hidden email]> wrote:
Hello John,

I'm trying to install the new version of HDBC on my Mac (ghc version is 6.10.1), and get the following error:

# cabal upgrade --global
Resolving dependencies...
'HDBC-2.0.0' is cached.
Configuring HDBC-2.0.0...
Preprocessing library HDBC-2.0.0...
Preprocessing executables for HDBC-2.0.0...
Building HDBC-2.0.0...
[1 of 7] Compiling Database.HDBC.SqlValue ( Database/HDBC/SqlValue.hs, dist/build/Database/HDBC/SqlValue.o )
[2 of 7] Compiling Database.HDBC.ColTypes ( Database/HDBC/ColTypes.hs, dist/build/Database/HDBC/ColTypes.o )
[3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/Statement.hs, dist/build/Database/HDBC/Statement.o )

Database/HDBC/Statement.hs:113:9:
   Type constructor `Exception' used as a class
   In the instance declaration for `Exception SqlError'
cabal: Error: some packages failed to install:
HDBC-2.0.0 failed during the building phase. The exception was:
exit: ExitFailure 1

I got the same error: Windows XP, GHC 6.10.1.
For some reason imported Control.Exception module appears to be 6.8.* version.

I got that error when using cabal to install. However, when I downloaded the package and installed it with a ./Setup.lhs configure..., it worked. Maybe this is a cabal issue instead.

Michael

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Krzysztof Skrzętnicki
In reply to this post by Krzysztof Skrzętnicki
On Sat, Jan 31, 2009 at 00:45, Krzysztof Skrzętnicki <[hidden email]> wrote:
On Sat, Jan 31, 2009 at 00:07, Valentyn Kamyshenko <[hidden email]> wrote:
Hello John,

I'm trying to install the new version of HDBC on my Mac (ghc version is 6.10.1), and get the following error:

# cabal upgrade --global
Resolving dependencies...
'HDBC-2.0.0' is cached.
Configuring HDBC-2.0.0...
Preprocessing library HDBC-2.0.0...
Preprocessing executables for HDBC-2.0.0...
Building HDBC-2.0.0...
[1 of 7] Compiling Database.HDBC.SqlValue ( Database/HDBC/SqlValue.hs, dist/build/Database/HDBC/SqlValue.o )
[2 of 7] Compiling Database.HDBC.ColTypes ( Database/HDBC/ColTypes.hs, dist/build/Database/HDBC/ColTypes.o )
[3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/Statement.hs, dist/build/Database/HDBC/Statement.o )

Database/HDBC/Statement.hs:113:9:
   Type constructor `Exception' used as a class
   In the instance declaration for `Exception SqlError'
cabal: Error: some packages failed to install:
HDBC-2.0.0 failed during the building phase. The exception was:
exit: ExitFailure 1

I got the same error: Windows XP, GHC 6.10.1.
For some reason imported Control.Exception module appears to be 6.8.* version.

I found a (temporary) fix: change dependancy in .cabal file to state "base >= 4". Otherwise cabal-install selects base-3 which is the cause of the problems.

All best

Christopher Skrzętnicki

 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Valentyn Kamyshenko
Thanks, Krzysztof - it worked for me.

Something is definitely wrong with cabal dependencies: even when HDBC-2.0.0 was installed, it tried to install it again (and failed) when I tried to install HDBC-postgresql and HDBC-sqlite3.
Manual installation (./Setup configure; ./Setup build; ./Setup install) worked.

Thank you for your help,

-- Valentyn.

On Jan 30, 2009, at 3:52 PM, Krzysztof Skrzętnicki wrote:

On Sat, Jan 31, 2009 at 00:45, Krzysztof Skrzętnicki <[hidden email]> wrote:
On Sat, Jan 31, 2009 at 00:07, Valentyn Kamyshenko <[hidden email]> wrote:
Hello John,

I'm trying to install the new version of HDBC on my Mac (ghc version is 6.10.1), and get the following error:

# cabal upgrade --global
Resolving dependencies...
'HDBC-2.0.0' is cached.
Configuring HDBC-2.0.0...
Preprocessing library HDBC-2.0.0...
Preprocessing executables for HDBC-2.0.0...
Building HDBC-2.0.0...
[1 of 7] Compiling Database.HDBC.SqlValue ( Database/HDBC/SqlValue.hs, dist/build/Database/HDBC/SqlValue.o )
[2 of 7] Compiling Database.HDBC.ColTypes ( Database/HDBC/ColTypes.hs, dist/build/Database/HDBC/ColTypes.o )
[3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/Statement.hs, dist/build/Database/HDBC/Statement.o )

Database/HDBC/Statement.hs:113:9:
   Type constructor `Exception' used as a class
   In the instance declaration for `Exception SqlError'
cabal: Error: some packages failed to install:
HDBC-2.0.0 failed during the building phase. The exception was:
exit: ExitFailure 1

I got the same error: Windows XP, GHC 6.10.1.
For some reason imported Control.Exception module appears to be 6.8.* version.

I found a (temporary) fix: change dependancy in .cabal file to state "base >= 4". Otherwise cabal-install selects base-3 which is the cause of the problems.

All best

Christopher Skrzętnicki

 


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

John Goerzen-3
In reply to this post by Michael Snoyman
On Fri, Jan 30, 2009 at 03:50:30PM -0800, Michael Snoyman wrote:
> >> [3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/Statement.hs,
> >> dist/build/Database/HDBC/Statement.o )
> >>
> >> Database/HDBC/Statement.hs:113:9:
> >>    Type constructor `Exception' used as a class
> >>    In the instance declaration for `Exception SqlError'
> >> cabal: Error: some packages failed to install:
> >> HDBC-2.0.0 failed during the building phase. The exception was:
> >> exit: ExitFailure 1

That's *WEIRD*.  

It's as if you have the old base from GHC 6.8.  Is cabal-install doing
something (weird|evil|smart) here?

That code is in this block:

#if __GLASGOW_HASKELL__ >= 610
  ...
instance Exception SqlError where
  ...
#endif

And it acts as if you're compiling against GHC 6.8!

> I got that error when using cabal to install. However, when I downloaded the
> package and installed it with a ./Setup.lhs configure..., it worked. Maybe
> this is a cabal issue instead.

Leads me to think even more that there's cabal-install trickery here.

Can someone enlighten us on that?  Is cabal-install playing tricks
with base?

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

John Goerzen-3
In reply to this post by Krzysztof Skrzętnicki
On Sat, Jan 31, 2009 at 12:52:02AM +0100, Krzysztof Skrz??tnicki wrote:
> > I got the same error: Windows XP, GHC 6.10.1.
> > For some reason imported Control.Exception module appears to be 6.8.*
> > version.
> >
>
> I found a (temporary) fix: change dependancy in .cabal file to state "base
> >= 4". Otherwise cabal-install selects base-3 which is the cause of the
> problems.

Thanks for the hint for folks.

Why would cabal-install select a different base than running Setup
manually?  

I can't hard-code base >= 4 into .cabal because that would break for
GHC 6.8 users.  I have CPP code that selects what to compile based on
GHC version.

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Austin Seipp
Excerpts from John Goerzen's message of Fri Jan 30 18:31:00 -0600 2009:
> Why would cabal-install select a different base than running Setup
> manually?  
>
> I can't hard-code base >= 4 into .cabal because that would break for
> GHC 6.8 users.  I have CPP code that selects what to compile based on
> GHC version.
>
> -- John

I think it would be easiest to simply not use CPP and set a dependency
on the extensible-exceptions package:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/extensible-exceptions

Using this package, you don't need CPP at all - just import
'Control.Exception.Extensible' instead of Control.Exception and you're
done. This package works under both ghc 6.8 and 6.10 (when compiled
under 6.10, it just re-exports all of Control.Exception, and on <=
6.10 it actually compiles the code) and means you don't have to have
two awkward copies of the same code that use different
exception-handling mechanisms.

Austin
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Niklas Broberg
In reply to this post by John Goerzen-3
> Thanks for the hint for folks.
>
> Why would cabal-install select a different base than running Setup
> manually?

Someone thought it was a good idea to make base-3 the preferred
selection for cabal-install, to make the transition from base-3 to
base-4 as smooth as possible. It may have worked for that, but it's
causing a lot of problems now instead. Time for a new policy/version
for cabal-install?

Cheers,

/Niklas
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Krzysztof Skrzętnicki
In reply to this post by John Goerzen-3
The following change in .cabal file may solve the problems:
---
flag base4
  description: Choose base-4 if possible
  default: True

library
  if flag(splitBase)
    if flag(base4)
      Build-Depends: base>=4, old-time, time, bytestring, containers, old-locale
    else
      Build-Depends: base>=3, old-time, time, bytestring, containers, old-locale
  else
    Build-Depends: base<3
  Build-Depends: mtl, convertible >= 1.0.1, utf8-string
---

It works for me and I *think* will also work for other setups, most notably GHC 6.8.*.

All best

Christopher Skrzętnicki

On Sat, Jan 31, 2009 at 01:31, John Goerzen <[hidden email]> wrote:
On Sat, Jan 31, 2009 at 12:52:02AM +0100, Krzysztof Skrz??tnicki wrote:
> > I got the same error: Windows XP, GHC 6.10.1.
> > For some reason imported Control.Exception module appears to be 6.8.*
> > version.
> >
>
> I found a (temporary) fix: change dependancy in .cabal file to state "base
> >= 4". Otherwise cabal-install selects base-3 which is the cause of the
> problems.

Thanks for the hint for folks.

Why would cabal-install select a different base than running Setup
manually?

I can't hard-code base >= 4 into .cabal because that would break for
GHC 6.8 users.  I have CPP code that selects what to compile based on
GHC version.

-- John


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

John Goerzen-3
On Sat, Jan 31, 2009 at 01:51:54AM +0100, Krzysztof Skrz??tnicki wrote:

> The following change in .cabal file may solve the problems:---
> flag base4
>   description: Choose base-4 if possible
>   default: True
>
> library
>   if flag(splitBase)
>     if flag(base4)
>       Build-Depends: base>=4, old-time, time, bytestring, containers,
> old-locale
>     else
>       Build-Depends: base>=3, old-time, time, bytestring, containers,
> old-locale
>   else
>     Build-Depends: base<3
>   Build-Depends: mtl, convertible >= 1.0.1, utf8-string
> ---
>
> It works for me and I *think* will also work for other setups, most notably
> GHC 6.8.*.

Not out of the box.  The base4 flag will be on by default for GHC
6.8.x too, and they'll get the base >= 4 dep, which will break.
They'd have to configure with the option to disable a flag (-f -base4
if memory serves), which is neither intuitive nor automatic.

The only option I would have is to disable all the new base 4 code and
make everyone have a dep on base<4.  That'd be a pity really; what's
the point of a new base if nobody can use it?

And annoying too, after I went to the effort to support it directly,
without OldException or a dep on base<4.

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

John Goerzen-3
In reply to this post by Austin Seipp
On Fri, Jan 30, 2009 at 06:40:29PM -0600, Austin Seipp wrote:

> Excerpts from John Goerzen's message of Fri Jan 30 18:31:00 -0600 2009:
> > Why would cabal-install select a different base than running Setup
> > manually?  
> >
> > I can't hard-code base >= 4 into .cabal because that would break for
> > GHC 6.8 users.  I have CPP code that selects what to compile based on
> > GHC version.
> >
> > -- John
>
> I think it would be easiest to simply not use CPP and set a dependency
> on the extensible-exceptions package:
>
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/extensible-exceptions
>
> Using this package, you don't need CPP at all - just import
> 'Control.Exception.Extensible' instead of Control.Exception and you're
> done. This package works under both ghc 6.8 and 6.10 (when compiled
> under 6.10, it just re-exports all of Control.Exception, and on <=
> 6.10 it actually compiles the code) and means you don't have to have
> two awkward copies of the same code that use different
> exception-handling mechanisms.

Interesting.

In its cabal file, I see this:

    if impl(ghc>=6.9)
        cpp-options: -DUSE_NEW_EXCEPTIONS
        build-depends: base>=4&&<5
    else
        build-depends: base<4

interesting, that.

Either:

  1) Everyone will have the same problem

or

  2) That magic somehow disables the cabal-install voodoo that's
     messing everyone up.

If it's #1, it doesn't help us.

If it's #2, I could do the same thing in HDBC.

Can anyone try to cabal-install extensible-exceptions on GHC 6.10 and
let me know what happens?

To be sure, I already had to use CPP for much of HDBC due to Hugs
issues.  I have a small bit of code in HDBC itself to deal with the
interface differences, and then the backend drivers mostly don't have
to care.  They can call throwSqlError which uses throwDyn or throw as
appropriate, and they can just be fine.  It is probably not necessary
to introduce another dep for the sake of saving as few lines of code
as this.

-- John

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Krzysztof Skrzętnicki
In reply to this post by John Goerzen-3


On Sat, Jan 31, 2009 at 04:01, John Goerzen <[hidden email]> wrote:
On Sat, Jan 31, 2009 at 01:51:54AM +0100, Krzysztof Skrz??tnicki wrote:
> The following change in .cabal file may solve the problems:---
> flag base4
>   description: Choose base-4 if possible
>   default: True
>
> library
>   if flag(splitBase)
>     if flag(base4)
>       Build-Depends: base>=4, old-time, time, bytestring, containers,
> old-locale
>     else
>       Build-Depends: base>=3, old-time, time, bytestring, containers,
> old-locale
>   else
>     Build-Depends: base<3
>   Build-Depends: mtl, convertible >= 1.0.1, utf8-string
> ---
>
> It works for me and I *think* will also work for other setups, most notably
> GHC 6.8.*.

Not out of the box.  The base4 flag will be on by default for GHC
6.8.x too, and they'll get the base >= 4 dep, which will break.
They'd have to configure with the option to disable a flag (-f -base4
if memory serves), which is neither intuitive nor automatic.

No, not really. I downloaded GHC 6.8.3 to test it, and it works:
 
D:\biblioteki\HDBC-2.0.0>cabal install -w c:\ghc\ghc-6.8.3\bin\ghc
Resolving dependencies...
Configuring HDBC-2.0.0.2...
Preprocessing library HDBC-2.0.0.2...
Preprocessing executables for HDBC-2.0.0.2...
Building HDBC-2.0.0.2...
[1 of 7] Compiling Database.HDBC.SqlValue ( Database/HDBC/SqlValue.hs, dist\build/Database/HDBC/SqlValue.o )
[2 of 7] Compiling Database.HDBC.ColTypes ( Database/HDBC/ColTypes.hs, dist\build/Database/HDBC/ColTypes.o )
[3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/Statement.hs, dist\build/Database/HDBC/Statement.o )

Database/HDBC/Statement.hs:15:0:
    Warning: Module `Control.Exception' is imported, but nothing from it is used,
               except perhaps instances visible in `Control.Exception'
             To suppress this warning, use: import Control.Exception()
[4 of 7] Compiling Database.HDBC.Types ( Database/HDBC/Types.hs, dist\build/Database/HDBC/Types.o )
[5 of 7] Compiling Database.HDBC.Utils ( Database/HDBC/Utils.hs, dist\build/Database/HDBC/Utils.o )
[6 of 7] Compiling Database.HDBC.DriverUtils ( Database/HDBC/DriverUtils.hs, dist\build/Database/HDBC/DriverUtils.o )
[7 of 7] Compiling Database.HDBC    ( Database/HDBC.hs, dist\build/Database/HDBC.o )
C:\ghc\ghc-6.10.1\bin\ar.exe: creating dist\build\libHSHDBC-2.0.0.2.a
Installing library in C:\Program Files\Haskell\HDBC-2.0.0.2\ghc-6.8.3
Registering HDBC-2.0.0.2...
Reading package info from "dist\\installed-pkg-config" ... done.
Saving old package config file... done.
Writing new package config file... done.

Checking:

C:\ghc\ghc-6.8.3\bin>ghc-pkg list HDBC
C:/ghc/ghc-6.8.3\package.conf:
    HDBC-2.0.0.2

So both 6.8.3 and 6.10.1 work as expected.

I can't remember the exact page in docs, but as far as i remember if Cabal fails to satisfy conditions with certain flag on its default settings the flag is changed and dependency calculation restarts.

All best

Christopher Skrzętnicki


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

John Goerzen-3
In reply to this post by Niklas Broberg
Niklas Broberg wrote:

>> Thanks for the hint for folks.
>>
>> Why would cabal-install select a different base than running Setup
>> manually?
>
> Someone thought it was a good idea to make base-3 the preferred
> selection for cabal-install, to make the transition from base-3 to
> base-4 as smooth as possible. It may have worked for that, but it's
> causing a lot of problems now instead. Time for a new policy/version
> for cabal-install?

I've just uploaded HDBC 2.0.1 to cabal, that has the same hack as
extensible-exceptions.  Would one of you that had trouble with
cabal-install on 2.0.0 please test and let me know if it's better?

Thanks,

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Valentyn Kamyshenko
Thank you John,

it worked like a charm :)

-- Valentyn.

On Jan 31, 2009, at 7:30 AM, John Goerzen wrote:

> Niklas Broberg wrote:
>>> Thanks for the hint for folks.
>>>
>>> Why would cabal-install select a different base than running Setup
>>> manually?
>>
>> Someone thought it was a good idea to make base-3 the preferred
>> selection for cabal-install, to make the transition from base-3 to
>> base-4 as smooth as possible. It may have worked for that, but it's
>> causing a lot of problems now instead. Time for a new policy/version
>> for cabal-install?
>
> I've just uploaded HDBC 2.0.1 to cabal, that has the same hack as
> extensible-exceptions.  Would one of you that had trouble with
> cabal-install on 2.0.0 please test and let me know if it's better?
>
> Thanks,
>
> -- John
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Duncan Coutts
In reply to this post by John Goerzen-3
On Fri, 2009-01-30 at 18:29 -0600, John Goerzen wrote:

> On Fri, Jan 30, 2009 at 03:50:30PM -0800, Michael Snoyman wrote:
> > >> [3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/Statement.hs,
> > >> dist/build/Database/HDBC/Statement.o )
> > >>
> > >> Database/HDBC/Statement.hs:113:9:
> > >>    Type constructor `Exception' used as a class
> > >>    In the instance declaration for `Exception SqlError'
> > >> cabal: Error: some packages failed to install:
> > >> HDBC-2.0.0 failed during the building phase. The exception was:
> > >> exit: ExitFailure 1
>
> That's *WEIRD*.  
>
> It's as if you have the old base from GHC 6.8.  Is cabal-install doing
> something (weird|evil|smart) here?

Yes.

> Leads me to think even more that there's cabal-install trickery here.

Yup.

> Can someone enlighten us on that?  Is cabal-install playing tricks
> with base?

Yes.

The difference (in the released version of cabal-install) between the
configure and install commands is that configure uses a dumb algorithm
for deciding what versions of dependencies to use while install uses a
smarter algorithm. Obviously this is confusing and in the next release
configure will use the smart algorithm too.

At the moment configure picks the latest versions of all packages
irrespective of whether this is likely to work or not. For developers
using ghc-6.10 with base 3 and 4 this means they end up with base 4.
They then likely do not notice that their package actually needs base
version 4.

The install command uses the constraint solver and takes into account
some global preferences from hackage. These are soft preferences / soft
constraints. They do not override constraints specified in the .cabal
file or on the command line. However for the huge number of packages on
hackage that worked with ghc-6.8 but failed to specify a constraint on
the version of base, using a preference of base 3 over base 4 enables
those packages to continue to build.

So in the next cabal-install release (which should be pretty soon now)
configure will do the same thing and pick base 3 unless you specify
build-depends base >= 4.

So the solution is for HDBC-2.0 to specify the version of base that it
needs more accurately. It appears that it does need version 4 so it
should use:

build-depends: base == 4.*


On a similar issue, I am going to make Hackage enforce that packages
specify an upper bounds on the version of base. Hopefully doing that
will make people also consider the appropriate lower bound. I don't see
an obvious way of automatically requiring accuracy in selecting the base
version between 3 and 4. It is perfectly possible to have a package that
works with both. Perhaps we should make not-specifying an upper bound an
error and not specifying a lower bound a warning.

Thoughts?

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Duncan Coutts
In reply to this post by John Goerzen-3
On Fri, 2009-01-30 at 18:31 -0600, John Goerzen wrote:

> I can't hard-code base >= 4 into .cabal because that would break for
> GHC 6.8 users.  I have CPP code that selects what to compile based on
> GHC version.

Ahh, but the version of base is no longer determined by the version of
GHC, so using cpp tests on the ghc version is not right (besides it does
not work for non-ghc if that is relevant).

In future (from Cabal-1.6 onwards) you can use macros to test the
version of the package rather than the version of ghc:

#if MIN_VERSION_base(4,0,0)
...
#endif

but since you are trying to support ghc-6.8 (and Cabal-1.2) you cannot
rely on these macros yet. You can use this trick:

flag base4

library
  if flag(base4)
    build-depends: base >= 4
    cpp-options:   -DBASE4
  else
    build-depends: base < 4

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Niklas Broberg
In reply to this post by Duncan Coutts
> So in the next cabal-install release (which should be pretty soon now)
> configure will do the same thing and pick base 3 unless you specify
> build-depends base >= 4.

... and so there will never be any incentive for these many packages
to migrate to base-4, which also has consequences for packages that do
want to use base-4, but also want to depend on such packages. And so
base-3 will live on in eternity, and there was never any point in
doing that new base release at all.

I really really think this is the wrong way to go. Occasional
destruction is desperately needed for progress, else things will
invariably stagnate.

I would suggest as a less stagnating approach to issue a warning/hint
when a package with no explicit version dependency for base fails to
build. The hint could suggest to the user trying to build the package
that they can use 'cabal instal --package=base-3'.

Cheers,

/Niklas
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANN: HDBC v2.0 now available

Duncan Coutts
On Sun, 2009-02-01 at 15:56 +0100, Niklas Broberg wrote:
> > So in the next cabal-install release (which should be pretty soon now)
> > configure will do the same thing and pick base 3 unless you specify
> > build-depends base >= 4.
>
> ... and so there will never be any incentive for these many packages
> to migrate to base-4, which also has consequences for packages that do
> want to use base-4, but also want to depend on such packages. And so
> base-3 will live on in eternity, and there was never any point in
> doing that new base release at all.

> I really really think this is the wrong way to go. Occasional
> destruction is desperately needed for progress, else things will
> invariably stagnate.

I disagree. Having everything fail (we measured it as ~90% of hackage)
when people upgraded to ghc-6.10 would have been a disaster. Do you
recall the screaming, wailing and gnashing of teeth after the release of
ghc-6.8 when most of hackage broke? We (I mean ghc and cabal hackers)
got a lot of flak for not making the upgrade process easier and
needlessly breaking everyone's  perfectly good packages.

This time round we went to a lot of effort to make the upgrade process
smooth. And for the most part it was. Only a small proportion of hackage
packages broke.

Now I agree that there is a problem with new packages where the
configure selects base 4 but install selects base 3. I've improved that
in the darcs version.

You're also right that during the lifespan of base 4 we need to
encourage new releases to start working with it because we cannot stick
with base 3 for ever. Doing that with warnings hints etc is the way to
go. Destruction is not such a friendly approach. We do not need to make
the users suffer, we just need to inform and persuade developers
uploading new releases to do the right thing.

Duncan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12