Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr
On 07/12/2010 21:30, Mitar wrote: Hi! On Wed, Dec 1, 2010 at 10:50 AM, Simon Marlowmarlo...@gmail.com wrote: Yes, but semantics are different. I want to tolerate some exception because they are saying I should do this and this (for example user interrupt, or timeout) but I do not want others, which somebody else maybe created and I do not want to care about them. Surely if you don't care about these other exceptions, then the right thing to do is just to propagate them? Why can't they be dealt with in the same way as user interrupt? The problem is that Haskell does not support getting back to (continue) normal execution flow as there was no exception. If you can't tolerate certain kinds of exceptions being thrown to a thread, then... don't throw them. If your intention is that the thread will continue after receiving a certain kind of exception, then handle the exception in a different thread instead. You have complete control over which asynchronous exceptions are thrown to a thread. You might argue that StackOverflow/HeapOverflow aren't under your control - but in fact StackOverflow will never be raised inside mask. If/when we ever implement HeapOverflow we'll make sure it has this property too. I've thought about whether we could support resumption in the past. It's extremely difficult to implement - imagine if the thread was in the middle of an I/O operation - should the entire I/O operation be restarted from the beginning? If the thread was blocked on an MVar, then it has to re-block on the same MVar - but maybe now the MVar is full. Should it be as if the thread was never unblocked? The only sensible semantics is that the exception behaves like an interrupt - but we already have support for that, just run the handler in a different thread. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build issue: * Missing header file: HsBase.h
On 10/12/2010 16:49, Karel Gardas wrote: Hello, I'm trying to recover my opensolaris builder machine after disk crash, but after reinstall I'm not able to build any GHC there. I'm trying head and now also 6.12.3 as a reference (as I'm able to build it on my workstation with the same OS). The problem I see here is when I invoke `gmake' then the process continues up to configuration of base library which fails with: checking value of ETIMEDOUT... 145 checking value of ETOOMANYREFS... 144 checking value of ETXTBSY... 26 checking value of EUSERS... 94 checking value of EWOULDBLOCK... 11 checking value of EXDEV... 18 checking value of ENOCIGAR... -1 checking value of SIGINT... 2 checking value of O_BINARY... 0 checking for library containing iconv... none required configure: creating ./config.status config.status: creating base.buildinfo config.status: creating include/HsBaseConfig.h configure: WARNING: unrecognized options: --with-compiler ghc-cabal: Missing dependency on a foreign library: * Missing header file: HsBase.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. gmake[1]: *** [libraries/base/dist-install/package-data.mk] Error 1 gmake: *** [all] Error 2 The problem is HsBase.h is where it is on my reference build tree on workstation: -bash-4.0$ find . -name 'HsBase.h' ./libraries/base/include/HsBase.h -bash-4.0$ I suppose some external library might be missing, but here the error is quite misleading and I cannot find which one might be the culprit of this error. Do you have any idea what to install in order to proceed? I don't know what's going on here, I'm afraid. Looks like Cabal tried to find HsBase.h and couldn't find it - so either it wasn't there (but you say it was), or Cabal was looking in the wrong place. Maybe follow up the latter hypothesis? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build issue: * Missing header file: HsBase.h
On 16 December 2010 10:02, Simon Marlow marlo...@gmail.com wrote: ghc-cabal: Missing dependency on a foreign library: * Missing header file: HsBase.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. The problem is HsBase.h is where it is on my reference build tree on workstation: -bash-4.0$ find . -name 'HsBase.h' ./libraries/base/include/HsBase.h I suppose some external library might be missing, but here the error is quite misleading and I cannot find which one might be the culprit of this error. Do you have any idea what to install in order to proceed? I don't know what's going on here, I'm afraid. Looks like Cabal tried to find HsBase.h and couldn't find it - so either it wasn't there (but you say it was), or Cabal was looking in the wrong place. Maybe follow up the latter hypothesis? Cabal will report this error when it cannot compile HsBase.h, that usually means it is missing, but it's also possible that something just does not compile. This is like the check that ./configure scripts do. It's rather hard from the exit code of gcc to work out if it's genuinely missing, or fails to compile (though we could try doing cpp and cc phases separately). One can run with -v3 to see the error that gcc reports. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build issue: * Missing header file: HsBase.h
Duncan and Simon, thank you very much for dealing with this. After adding -v3 to the ghc-cabal invocation it reported gcc error on HsBase.h due to missing math.h file, i.e. system/library/math/header-math package was not installed yet. Thanks! Karel On 12/16/10 11:16 AM, Duncan Coutts wrote: Do you have any idea what to install in order to proceed? I don't know what's going on here, I'm afraid. Looks like Cabal tried to find HsBase.h and couldn't find it - so either it wasn't there (but you say it was), or Cabal was looking in the wrong place. Maybe follow up the latter hypothesis? Cabal will report this error when it cannot compile HsBase.h, that usually means it is missing, but it's also possible that something just does not compile. This is like the check that ./configure scripts do. It's rather hard from the exit code of gcc to work out if it's genuinely missing, or fails to compile (though we could try doing cpp and cc phases separately). One can run with -v3 to see the error that gcc reports. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Newtype deriving mixing up types
Hello! I attach a program which I suspect demonstrates a bug in GHC. The important lines are: showType :: forall a . Expr a - String showType (Lit _) = show (typeOf (undefined :: a)) test1 = showType (mk :: Expr BOOL) -- Prints Bool (wrong?) test2 = showType (Lit mk :: Expr BOOL) -- Prints Main.BOOL (correct) test1 and test2 give different results, even though showType shouldn't be able to tell them apart. It seems that the Typeable context packed with the Lit constructor is wrong in test2. I had to use two extra classes and newtype deriving to trigger this behavior. Note that if I change deriving instance B BOOL to instance B BOOL the result is correct. Tested with both 6.12.3 and 7.0.1. Should I report this as a bug? Thanks! / Emil import Data.Typeable data Expr a where Lit :: Typeable a = a - Expr a class A a where mk :: a class (Typeable a, A a) = B a where mkExpr :: Expr a mkExpr = Lit mk instance B a = A (Expr a) where mk = mkExpr instance A Bool where mk = True newtype BOOL = BOOL Bool deriving (Typeable, A) instance B Bool deriving instance B BOOL showType :: forall a . Expr a - String showType (Lit _) = show (typeOf (undefined :: a)) test1 = showType (mk :: Expr BOOL) -- Prints Bool (wrong?) test2 = showType (Lit mk :: Expr BOOL) -- Prints Main.BOOL (correct) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC 7.0.2 Release Candidate 1
We are pleased to announce the first release candidate for GHC 7.0.2: http://www.haskell.org/ghc/dist/7.0.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.2 Release Candidate 1
Way to go! Are there tentative release notes, so I know what to look for? Thanks, Antoine On Thu, Dec 16, 2010 at 12:36 PM, Ian Lynagh ig...@earth.li wrote: We are pleased to announce the first release candidate for GHC 7.0.2: http://www.haskell.org/ghc/dist/7.0.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr
Hi!
On Thu, Dec 16, 2010 at 10:30 AM, Simon Marlow marlo...@gmail.com wrote:
I've thought about whether we could support resumption in the past. It's
extremely difficult to implement - imagine if the thread was in the middle
of an I/O operation - should the entire I/O operation be restarted from the
beginning?
Yes, this is the same problem as when designing an operating system:
what should happen to a system call if it is interrupted. And I agree
with elegance of simply returning EINTR errno. This makes system calls
much easier to implement and for user it is really simple to wrap it
in a loop retrying it. So it is quite often to see such function:
static int xioctl( int fd, int request, void *arg) {
int r;
do {
r = ioctl(fd, request, arg);
} while (-1 == r EINTR == errno);
return r;
}
And this is why, once I recognized similarities decided to use my
uninterruptible function. So as resumption is hard to do then such
approach is a valid alternative.
I agree with you, that the best would be that there would be no need
for such functions as you would make sure that exceptions are raised
only in threads you want. But this is hard to really satisfy when
using complex programs with many threads and many exception throwing
between them and especially if you are using third-party libraries you
do not know much about and which could throw some exception to some
other thread you haven't expected. This is why it is good to make sure
that things will work as expected even if some exception leaks in. It
would be great if type system would help you here: maybe a separate
(type) system just for exception coverage checking which would build a
graph from code of how all could exceptions be thrown (this would
require following of how ThreadId values are passed around, as
capability tokens for throwing an exception) and inform/warn you about
which exceptions can be thrown in which code segments. And you could
specify which exceptions you predict/allow and if there would be a
mismatch you would get an compile-time error.
Mitar
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
