Not screening. This one is tricky, because I don't really understand the
semantics of either the old or the new functions very well, and I also don't
know whether mask is supported by all the build-depends versions we need to
support.

Not very important, just a small step towards -fwarn-as-error with GHC 7.

Yours,
   Petr

1 patch for repository http://darcs.net/screened:

Wed Apr 27 03:12:50 CEST 2011  Petr Rockai <me@mornfall.net>
  * Fix a couple of GHC 7 deprecation warnings.

Attachments

• fix-a-couple-of-ghc-7-deprecation-warnings_.dpatch
• unnamed
• unnamed

On Wed, Apr 27, 2011 at 01:25:14AM +0000, Petr Ročkai wrote:
> Not screening. This one is tricky, because I don't really understand the
> semantics of either the old or the new functions very well,

Well, mask is defined in terms of block anyway, it's just a restriction
to make sure the programmer does screw things up with unbalanced
block/unblock (in the case of libraries in particular):

-- from IO.hs
mask io = do
  b <- getMaskingState
  case b of
    Unmasked -> block $ io unblock
    _        -> io id

>  and I also don't know whether mask is supported by all the
>  build-depends versions we need to support.

No idea, sorry.


> hunk ./src/Darcs/Global.hs 66
> -    exit = block $ do
> +    exit = mask $ \unmask -> do
>          Just actions <- swapMVar atexitActions Nothing
>          -- from now on atexit will not register new actions
> hunk ./src/Darcs/Global.hs 69
> -        mapM_ runAction actions
> -    runAction action = do
> -        catch (unblock action) $ \(exn :: SomeException) -> do
> +        mapM_ (runAction unmask) actions
> +    runAction unmask action = do
> +        catch (unmask action) $ \(exn :: SomeException) -> do

This one looks good to me.  It changes the semantics, of course, but the
new semantics is supposed to be safer and in that case I cannot see how
it would hurt the computation in any way (it only about error reporting
after all, which could be caught at a higher level now but for good
reasons).

>  
> hunk ./src/Darcs/IO.hs 18
>  withSignalsBlocked :: IO a -> IO a
> -withSignalsBlocked job = block (job >>= \r ->
> -                           unblock(return r) `catchSignal` couldnt_do r)
> +withSignalsBlocked job = mask $ \unmask -> (job >>= \r ->
> +                                           unmask (return r) `catchSignal` couldnt_do r)

I am sure that this one is correct.  I remember I rewrote the code that
way to allow such easy block/mask substitution.

I think you can screen this patch.

Best,
-- 
Gabriel

Gabriel Kerneis wrote:
>>  and I also don't know whether mask is supported by all the
>> build-depends versions we need to support.
> 
> No idea, sorry.
[...]
> I think you can screen this patch.

Not until we check on that. I don't think mask is in GHC 6.10 and I'm not sure about 6.12. I think we can definitely drop 6.10 support after we release 2.8, and there may be a case for doing so before.

Ganesh

=============================================================================== 
Please access the attached hyperlink for an important electronic communications disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
===============================================================================

On Wed, Apr 27, 2011 at 08:46:24AM +0100, Sittampalam, Ganesh wrote:
> Gabriel Kerneis wrote:
> >>  and I also don't know whether mask is supported by all the
> >> build-depends versions we need to support.
> > 
> > No idea, sorry.
> [...]
> > I think you can screen this patch.
> 
> Not until we check on that. I don't think mask is in GHC 6.10 and I'm not
> sure about 6.12. I think we can definitely drop 6.10 support after we release
> 2.8, and there may be a case for doing so before.

In case you need to retain compatibility, you can still do:
mask io = block $ io unblock

It will work and keep the old semantics for old compilers (this requires some
compiler-version checks, though, that I do not know how to perform, but I am
sure it is possible).

-- 
Gabriel

setting this as in-discussion until a conclusion is reached on how to do 
this (mask in terms of block seems like the obvious way to go)

It seems that the problem has been solved by Ganesh's patch "switch from 
block/unblock to mask".