On 4/23/2009 02:05, Duncan Coutts wrote:

On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote:

...

Hi Ian,

thanks for the update on plans and the willingness to jump in and do another release cycle so soon after 6.10.2. The suggested fixes seem agreeable to me, but I have one _minor_ additional request for 6.10.3 if you end having to rebuild 'base' -- add a DEPRECATED (or some such) to Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} to indicate that the operational behaviour of these have changed.

Small change, but could be helpful to package users&authors when migrating beyond 6.10.1

I agree that it's a little unfortunate that this change is in a minor release.

I'm not sure what can be done as far as automatic messages go however. The notice about the change is in the release notes. The functions are not deprecated (they're part of the FFI spec).

Sorry, didn't mean to imply that they were. Just offered it as a pragmatic solution to deliver extra help to folks without spending the dev. time to implement a more appropriate pragma like WARNING/INFO. If such a thing already existed... --sigbjorn

2009/4/23 Duncan Coutts :

On Thu, 2009-04-23 at 05:59 -0700, Sigbjorn Finne wrote:

...

On 4/23/2009 02:05, Duncan Coutts wrote:

...

On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote:

...

Hi Ian,

thanks for the update on plans and the willingness to jump in and do another release cycle so soon after 6.10.2. The suggested fixes seem agreeable to me, but I have one _minor_ additional request for 6.10.3 if you end having to rebuild 'base' -- add a DEPRECATED (or some such) to Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} to indicate that the operational behaviour of these have changed.

Small change, but could be helpful to package users&authors when migrating beyond 6.10.1

I agree that it's a little unfortunate that this change is in a minor release.

I'm not sure what can be done as far as automatic messages go however. The notice about the change is in the release notes. The functions are not deprecated (they're part of the FFI spec).

Sorry, didn't mean to imply that they were. Just offered it as a pragmatic solution to deliver extra help to folks without spending the dev. time to implement a more appropriate pragma like WARNING/INFO. If such a thing already existed...

For INFO we'd want a mechanism to have it tell us the first time but once we acknowledge the info, for it not to keep bugging us or our users every time. Hmm, tricky.

We do have a WARNING pragma, incedentally: http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning... Cheers, Simon

Ian Lynagh:

On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote:

...

We do have a WARNING pragma, incedentally:

http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning...

I don't think that using it for this would be a good idea, though. It would mean that people who really do want Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} would not be able to write warning-free code.

I agree. Manuel

On 27/04/2009 01:28, Sigbjorn Finne wrote:

On 4/25/2009 07:16, Ian Lynagh wrote:

...

On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote:

...

We do have a WARNING pragma, incedentally:

http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning...

I don't think that using it for this would be a good idea, though. It would mean that people who really do want Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} would not be able to write warning-free code.

Repeating myself, I suppose :) , but I would be happy to take that "hit" for 6.10.3 if it avoids other GHC users from spending unproductive time getting on top of this change. ymmv.

As a compromise, how about expanding the runtime error message to make it clear that this is a change in 6.10.2? finalizer: error: a C finalizer called back into Haskell. This was previously allowed, but is disallowed in GHC 6.10.2 and later. To create finalizers that may call back into Haskll, use Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr. Cheers, Simon

Hi, Perhaps it would make sense to add something along those lines to the documentation for Foreign.newForeignPtr as well? -Iavor On Mon, Apr 27, 2009 at 5:32 AM, Simon Marlow wrote:

On 27/04/2009 01:28, Sigbjorn Finne wrote:

...

On 4/25/2009 07:16, Ian Lynagh wrote:

...

On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote:

...

We do have a WARNING pragma, incedentally:

http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning...

I don't think that using it for this would be a good idea, though. It would mean that people who really do want Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer} would not be able to write warning-free code.

Repeating myself, I suppose :) , but I would be happy to take that "hit" for 6.10.3 if it avoids other GHC users from spending unproductive time getting on top of this change. ymmv.

As a compromise, how about expanding the runtime error message to make it clear that this is a change in 6.10.2?

finalizer: error: a C finalizer called back into Haskell.   This was previously allowed, but is disallowed in GHC 6.10.2 and later.   To create finalizers that may call back into Haskll, use   Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr.

Cheers,        Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Apr 22, 2009, at 22:00 , Alexander Dunlap wrote:

On Wed, Apr 22, 2009 at 4:56 PM, Ian Lynagh wrote:

...

An exception to this rule is that we will probably also rebundle time in the bindists, as that has little chance of breaking anything else.

Would this be a good time to add the "time" package too, or has that issue been resolved?

... -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH