headers
Duncan Coutts | 1 Nov 2008 21:57
Picon
Picon
Favicon

Re: cabal

On Tue, 2008-10-21 at 10:51 +0200, Christian Maeder wrote:

> So network-2.2.0.0 should be linked against base-3 within the binary
> dist of ghc-6.10 (or not shipped with ghc-6.10 at all.
> 
> In fact it worked after I've unregistered my global network-2.2.0.0,
> first! (but I didn't get much further, see below)

network-2.2.0.1 is now on hackage which should resolve the issue.

> > Normally cabal-install would use base-3 but in this case it's picking 4
> > because the version that is already installed used 4 so the assumption
> > is that since the same version is already installed then it does indeed
> > work with base 4. Of course that's not true here because the package has
> > changed without the version being bumped.
> 
> Or cabal-install should be smarter (or less smart).

Unfortunately it cannot be less smart or it'd try rebuilding haskell98
against base 3.

> So why is the version of network not bumped, yet? The maintainer is
> libraries <at> haskell.org. Would it interfere with ghc-6.8?

Done, and it works with (at least) ghc-6.6.1, 6.8.2 and 6.10.0.recent.

Duncan
Permalink | Reply | 0 comments |
headers
Jason Dagit | 2 Nov 2008 02:15

Re: Control.Exception

On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow <marlowsd <at> gmail.com> wrote:
> Johannes Waldmann wrote:
>>
>> with 6.10, the following does not typecheck:
>>
>> foo `Control.Exception.catch` \ _ -> return bar
>>
>> Ambiguous type variable `e' in the constraint:
>>      `Control.Exception.Exception e'
>>
>> It is probably bad programming style anyway but what is the workaround?
>
> As long as you're aware that it is bad programming style.  We deliberately
> didn't include an easy way to do this, because we want people to think about
> why they need to catch *all* exceptions (most of the time it's a bug).

Since the above is bad form, what should I be doing?  Could someone
please provide some examples or point me at the list of exceptions
that I can catch?  What about catching multiple types of exceptions?

Thanks,
Jason
Permalink | Reply | 14 comments |
headers
Sigbjorn Finne | 2 Nov 2008 03:09
Favicon

Re: Control.Exception

(+1) to that request - what is the "best practices" for portable exception
handling code that straddles version 6.10, i.e. that compiles with compilers
at either side with minimal fuss? I can imagine a couple of 
alternatives, but
would like to hear what others are doing here.

thanks
--sigbjorn "likes backward code compatibility"

On 11/1/2008 18:15, Jason Dagit wrote:
> On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow <marlowsd <at> gmail.com> wrote:
>   
>> Johannes Waldmann wrote:
>>     
>>> with 6.10, the following does not typecheck:
>>>
>>> foo `Control.Exception.catch` \ _ -> return bar
>>>
>>> Ambiguous type variable `e' in the constraint:
>>>      `Control.Exception.Exception e'
>>>
>>> It is probably bad programming style anyway but what is the workaround?
>>>       
>> As long as you're aware that it is bad programming style.  We deliberately
>> didn't include an easy way to do this, because we want people to think about
>> why they need to catch *all* exceptions (most of the time it's a bug).
>>     
>
> Since the above is bad form, what should I be doing?  Could someone
> please provide some examples or point me at the list of exceptions
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Schilling | 2 Nov 2008 14:32
Gravatar

Re: Control.Exception

I think the best way to get backwards compatibility is to flesh out
and use the extensible-exceptions package that Ian started, which
models extensible exceptions on top of the old exception mechanism.
Alternatively, you can decide not to use extensible exceptions and
have your package depend on base-3 instead of base-4.

For a library, however, I don't think there's a good solution, since
most of the time changing the exception mechanism for the library will
make the library incompatible with existing clients.  I guess the best
way to deal with this is to properly use the package versioning policy
and hope that clients specify their dependencies precisely.

2008/11/2 Sigbjorn Finne <sof <at> galois.com>:
> (+1) to that request - what is the "best practices" for portable exception
> handling code that straddles version 6.10, i.e. that compiles with compilers
> at either side with minimal fuss? I can imagine a couple of alternatives,
> but
> would like to hear what others are doing here.
>
> thanks
> --sigbjorn "likes backward code compatibility"
>
> On 11/1/2008 18:15, Jason Dagit wrote:
>>
>> On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow <marlowsd <at> gmail.com> wrote:
>>
>>>
>>> Johannes Waldmann wrote:
>>>
>>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Duncan Coutts | 2 Nov 2008 15:44
Picon
Picon
Favicon

Re: Control.Exception

On Sat, 2008-11-01 at 19:09 -0700, Sigbjorn Finne wrote:
> (+1) to that request - what is the "best practices" for portable exception
> handling code that straddles version 6.10, i.e. that compiles with compilers
> at either side with minimal fuss? I can imagine a couple of 
> alternatives, but
> would like to hear what others are doing here.

As far as I know there is no nice easy way to be compatible with both
models. There's no subset you can stick to that works with both.

In libraries like Cabal and other libs we've done things like:

catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a
#ifdef BASE4
catchIO = Exception.catch
#else
catchIO = Exception.catchJust Exception.ioErrors
#endif

catchExit :: IO a -> (ExitCode -> IO a) -> IO a
#ifdef BASE4
catchExit = Exception.catch
#else
catchExit = ... etc ...
#endif

The point is, the old catch deals with just one exception type, while
the new one works with various kinds of specific exception types. So
you'd need one of these ifdefs for each type of exception you're
catching.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Jarc | 3 Nov 2008 02:37
Picon

Re: ANNOUNCE: GHC 6.10.1 RC 1

Ian Lynagh <igloo <at> earth.li> wrote:
> I thought all your problems boiled down to binaries not being able to
> find libgmp.so at runtime? So I think this should fix them all.

Yes, but then I wouldn't be able to find and fix the commands that are
missing SRC_HC_OPTS. :)  So I'm holding off on that for now.  Below is
a patch for the ones I've found so far.  With those changes, and
without setting LD_LIBRARY_PATH, the build stops here:

Preprocessing library hpc-0.5.0.2...
dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make: error while loading shared libraries:
libgmp.so.3: cannot open shared object file: No such file or directory
running dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make failed
command was: dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make  >dist-bootstrapping/build/Trace/Hpc/Reflect.hs

My BUILD_FLAGS includes --ghc-option=-optl... and --ld-option=...
flags which would take care of it, if they were being used, so
apparently they're not.  libraries/hpc/Trace/Hpc/Reflect.hsc produces
libraries/hpc/dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make.c,
which is compiled and linked to make
libraries/hpc/dist-bootstrapping/build/Trace/Hpc/Reflect_hsc_make.  Is
there anything I can add to the cabal-bin command line to inject
linker flags into that link command?

--- libraries/Makefile	2008-10-07 15:30:24.000000000 -0400
+++ libraries/Makefile	2008-10-31 11:58:25.000000000 -0400
 <at>  <at>  -131,21 +131,21  <at>  <at> 

 cabal-bin: cabal-bin.hs
 	-mkdir bootstrapping
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philip K.F. Hölzenspies | 3 Nov 2008 12:29
Picon
Picon
Favicon

No atomic read on MVar?

Dear GHCers,

I ran face first into an assumption I had made on MVar operations (in 
Control.Concurrent); I had assumed there to be an atomic read (i.e. 
non-destructive read, as opposed to destructive consume/take). The following 
program illustrates what I had in mind.

testAtomic :: IO ()
testAtomic = do
	var <- newMVar 0
	putStrLn("Fork")
	forkIO (putMVar var 1 >> putStrLn "X")
	yield
	r1 <- readMVar var
	putStrLn("1")
	r2 <- takeMVar var
	putStrLn("2")
	r3 <- takeMVar var
	putStrLn("Result: " ++ show [r1,r2,r3])

If readMVar had been atomic, the result would be program termination with a 
result of [0,0,1] being output. However, readMVar simply combines takeMVar 
and putMVar, so the reading of r1 blocks after the takeMVar, because upon 
taking the MVar, the blocked thread wakes up, puts 1 in var and prints X. 
readMVar does not terminate for r1 (i.e. "1" is never printed).

I have now implemented my variable as a pair of MVars, one of which serves as 
a lock on the other. Both for performance reasons and for deadlock analysis, 
I would really like an atomic read on MVars, though. Does it exist? If not, 
why not?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Simon Marlow | 3 Nov 2008 13:34
Picon

Re: could ghci debugger search for free variables better?

Peter Hercek wrote:
> Simon Marlow wrote:
>> We thought about this when working on the debugger, and the problem is 
>> that to make the debugger retain all the variables that are in scope 
>> rather than just free in the expression adds a lot of overhead, and it 
>> fundamentally changes the structure of the generated code: everything 
>> becomes recursive, for one thing.  Well, perhaps you could omit all 
>> the recursive references (except the ones that are also free?), but 
>> there would still be a lot of overhead due to having to retain all 
>> those extra references.
>>
>> It also risks creating serious space leaks, by retaining references to 
>> things that the program would normally discard.
>>
>> Fortunately it's usually easy to work around the limitation, just by 
>> adding extra references to your code, e.g. in a let expression that 
>> isn't used.
> 
> Yes, Pepe pointed this to me too along with the "Step inside
>  GHCi debugger" paper in monad reader. The problem is that
>  I mostly can find out what is wrong when I look at values of
>  some important variables when some important place in my code
>  is hit. Using the trick with const function to manually add
>  references is not that much better than simple "printf
>  debugging" (adding Debug.Trace.trace calls to the code).
>  Tracing the execution history is nice too but it provides
>  much more than what is needed and obscures the important parts.
> 
> OK, It is frustrating that I find "printf debugging" often more
>  productive than ghci debugger.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Marlow | 3 Nov 2008 13:40
Picon

Re: Dilemma: DiffArray non-performance vs STArray non-readability

Claus Reinke wrote:
> I keep wanting to use DiffArray as the natural functional solution to
> single-threaded array use. But everytime I try, I get smacked over
> the head with the actual performance figures. Sometimes, even plain
> arrays are faster in a loop doing array updates, in spite of all the 
> copying involved. And when copying on update dominates the runtime, 
> using IntMap tends to be faster - the "indirections" are the wrong way
> round, but don't pile up, just that array lookups aren't quite constant
> time.
> 
> But when I really need to avoid the updates, and need constant
> time lookup, I'm stuck: DiffArray tends to slow everything down
> (I vaguely recall locks and threads being at the heart of this, but
> I haven't checked the code recently), so my only option seems to
> be to transform my nice functional code into not-nice sequential code 
> and use STArray.
> 
> Is there any way out of this dilemma? What do other Ghc users use?
> 
> If locks really are the issue, perhaps using STM instead of MVars
> in the DiffArray implementation could help. As long as my array uses are 
> single-threaded, STM optimism might be able to avoid
> waiting/scheduler issues? Or am I on the wrong track?

It needs to be thread-safe, but I imagine that using atomicModifyIORef 
rather than STM or MVars is the way to get good performance here.

> PS Btw, I thought the DiffArray performance issue was ancient,
>        but I can't find a ticket for it, nor does the haddock page for
>        Data.Array.Diff mention this little hickup. Should I add a ticket?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 3 Nov 2008 14:24
Picon

Re: Control.Exception

Jason Dagit wrote:
> On Wed, Oct 8, 2008 at 1:19 AM, Simon Marlow <marlowsd <at> gmail.com> wrote:
>> Johannes Waldmann wrote:
>>> with 6.10, the following does not typecheck:
>>>
>>> foo `Control.Exception.catch` \ _ -> return bar
>>>
>>> Ambiguous type variable `e' in the constraint:
>>>      `Control.Exception.Exception e'
>>>
>>> It is probably bad programming style anyway but what is the workaround?
>> As long as you're aware that it is bad programming style.  We deliberately
>> didn't include an easy way to do this, because we want people to think about
>> why they need to catch *all* exceptions (most of the time it's a bug).
> 
> Since the above is bad form, what should I be doing?  Could someone
> please provide some examples or point me at the list of exceptions
> that I can catch?  What about catching multiple types of exceptions?

Let's distinguish two kinds of exception handling:

1. Cleaning up.  If you want to catch errors in order to clean up - release 
resources, remove temporary files, that sort of thing - then use bracket or 
finally.  Behind the scenes, these catch all exceptions, but crucially they 
re-throw the exception after cleaning up, and they do the right 
block/unblock stuff for asynchronous exceptions.

2. Recovery.  You want to catch certain kinds of exception in order to 
recover and do something else, e.g. when calling getEnv.  In that case, I 
recommend using try or tryJust.
(Continue reading)

Permalink | Reply | 10 comments |

Gmane