[Haskell-cafe] What is the surefire way to handle all exceptions and make sure the program doesn't fail?
First of all, apologise if the question is too broad. The background goes like this: I've implemented a server program in Haskell for my company intended to replace the previous one written in C which crashes a lot (and btw the technology of the company is exclusively C-based). When I chose Haskell I promised my manager (arrogantly - I actually made a bet with him), it won't crash. Now it has been finished (with just a few hundred LOC), and my test shows that it is indeed very stable. But by looking at the code again I'm a little worried, since I'm rather new to exception handling and there're many networking-related functions in the program. I was tempted to catch (SomeException e) at the very top-level of the program and try to recursively call main to restart the server in case of any exception being thrown, but I highly doubt that is the correct and idiomatic way. There are also a number of long-running threads launched from the main thread, and exceptions thrown from these threads can't be caught by the top-level `catch' in the main thread. My main function looks like this: main :: IO () main = withSocketsDo $ do sCameraU - socketNewPassive False 6000 sStunU - socketNewPassive False 3478 sCmdT- socketNewPassive True 7000 mvarCam - newMVar M.empty mvarLog - newMVar [] forkIO $ regCamera sCameraU mvarCam mvarLog forkIO $ updCamera mvarCam mvarLog forkIO $ stun sCameraU sStunU mvarCam mvarLog listen sCmdT 128 processCmd sCmdT mvarCam mvarLog sClose sCameraU sClose sStunU sClose sCmdT I find that I can't tell whether a function will throw any exception at all, or what exceptions will be thrown, by looking at their documentation. I can only tell if I browse the source code. So the question is, how can I determine all the exceptions that can be thrown by a given function? And what is the best way to handle situations like this, with both the long-running threads and main thread need to be restarted whenever exceptions happen. Regards, Yifan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell's type inference considered harmful [Re: [Haskell] A riddle...]
[Is Haskell-Cafe the right place to discuss DESIGN issues of the Haskell
language? This message is not about a concrete problem...]
Congratulations to all that solved the riddle so quickly. (First answer
in only 8 Minutes!) Now to the point of the exercise: Shocking
realizations.
1. Haskell's type inference is NON-COMPOSITIONAL!
In the riddle below, I am defining two things f (rgbliste) and g
(farbliste). Even though they are not strongly connected, but g comes
after f in the definition order, the code of g influences the type of f.
THAT'S WRONG! :-(
It gets worse:
2. DEAD CODE changes a program's result!
Yes indeed. Dead code (farbliste) in the source cannot be removed
safely. And:
3. Haskell casts 181935629 to Word16 value 7693 WITHOUT WARNING!
Needless to say, these are serious problems for leading-edge strongly
typed language. The experts are probably aware of this. But I awoke
harshly from a sweet dream.
Issue 3 is quite harmful and reminds me more of C than of a strongly
typed language. Fixing this is not trivial. The problem is that all
numeric constants have type Num a = a, and of course, type variable a
can be instantiated to Int Word16 or whatever. Numeric constants need
to inhabit subclasses of Num, e.g., Word16, Int and Integer /classes/ to
make this behavior go away.
Update: There is nothing wrong with Word16 computing modulo 2^16, but a
literal like 181935629 should not get type Word16 without warning. Java
asks for explicit casts in
byte i = (byte) 1234876;
but mindlessly also in
byte i = (byte) 123;
which is not a great solution either.
Issues 1/2 go away with
{-# LANGUAGE NoMonomorphismRestriction #-}
(thx to Christian who pointed me to this). I wonder why this is not on
by default?! There seems to be an unresolved dispute about this...
http://hackage.haskell.org/trac/haskell-prime/wiki/NoMonomorphismRestriction
But even with MonomorphismRestriction, issue 1/2 are avoidable with a
more refined approach to type meta variables in the Haskell type
inference: After type-checking a strongly connected component, type
meta variables created for this part of the Haskell program should not
be instantiated in the (topologically) later defined parts of the
program. YOU DON'T WANT THE USE OF A FUNCTION INFLUENCE ITS DEFINITION!
There are two alternatives what to do with remaining meta-variables of
a SCC:
1. With monomorphism restriction: instantiate to the best type.
In our example below, Haskell chooses Integer.
2. Without monomorphism restriction: generalize.
Choice 1 will give an error in the program below, but i rather have an
error than a silent change of behavior of my program!
Cheers,
Andreas
P.S.: In Agda, in the situation of unsolved metas in an SCC (a mutual
block), these metas are just frozen, triggering typing errors later
(since Agda cannot generalize). The user has to go back an insert more
type annotations. But this is safe, whereas silent late instantiation
breaks compositionality.
On 16.07.2012 17:25, Andreas Abel wrote:
Today a student came to me with a piece of code that worked it executed
by itself, but produced different result in the context of his larger
problem. We cut down the example to the following:
import Graphics.UI.Gtk
-- should produce [(26471,0,65535),...
rgbliste =
(map (\ i -
let rb = 5 * (mod (mod 181935629 (4534+i)) 100)-250+128 in
let gb = 5 * (mod (mod 128872693 (5148+i)) 100)-250+128 in
let bb = 5 * (mod (mod 140302469 (7578+i)) 100)-250+128 in
let r = min 255 $ max 0 rb in
let g = min 255 $ max 0 gb in
let b = min 255 $ max 0 bb in
(r*257,g*257,b*257)) [0..])
--farbliste = map (\ (r,g,b) - Color r g b) rgbliste
main :: IO ()
main = do
print $ head rgbliste
If you run it, it prints (26471,0,65535).
If you uncomment the def. of farbliste, it prints (44461,65535,65535).
I was surprised. What is going on?
Cheers,
Andreas
--
Andreas AbelDu bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's type inference considered harmful [Re: [Haskell] A riddle...]
On 17 July 2012 09:27, Andreas Abel andreas.a...@ifi.lmu.de wrote: 1. Haskell's type inference is NON-COMPOSITIONAL! In the riddle below, I am defining two things f (rgbliste) and g (farbliste). Even though they are not strongly connected, but g comes after f in the definition order, the code of g influences the type of f. THAT'S WRONG! :-( Bindings at the same level in Haskell are mutually recursive. Order of declaration does not matter. These two terms are unified by the type system. So I'm not sure what you expect to happen here. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Non-greedy match in Text.Regx.Posix
Hi all, I was exploring Text.Regex.Posix and found that I was not able to do a non-greedy match by modifying the quantifier with a ?. How can I achieve non-greedy match in Text.Regex.Posix? Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's type inference considered harmful [Re: [Haskell] A riddle...]
You will be warned about the top-level definitions not including a type-signature if you use the -Wall flag. This isn't really a complete solution to your gripes, but it does address the change in behaviour that you saw when adding/removing the commented code, and would draw your attention to the logical error of trying to squeeze numbers that were too large into a Word16. I've been caught by unwarned truncation of numeric literals before too, so it would be great if there were warnings for this. On Tue, Jul 17, 2012 at 3:40 PM, Christopher Done chrisd...@gmail.com wrote: On 17 July 2012 09:27, Andreas Abel andreas.a...@ifi.lmu.de wrote: 1. Haskell's type inference is NON-COMPOSITIONAL! In the riddle below, I am defining two things f (rgbliste) and g (farbliste). Even though they are not strongly connected, but g comes after f in the definition order, the code of g influences the type of f. THAT'S WRONG! :-( Bindings at the same level in Haskell are mutually recursive. Order of declaration does not matter. These two terms are unified by the type system. So I'm not sure what you expect to happen here. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's type inference considered harmful
1. Haskell's type inference is NON-COMPOSITIONAL!
Yes, it is -- and there are many examples of it. Here is an example
which has nothing to do with MonomorphismRestriction or numeric
literals
{-# LANGUAGE ExtendedDefaultRules #-}
class C a where
m :: a - Int
instance C () where
m _ = 1
instance C Bool where
m _ = 2
main = do
x - return undefined
let y = x
print . fst $ (m x, show x)
-- let dead = if False then not y else True
return ()
The program prints 1. If you uncomment the (really) dead code, it will
print 2. Why? The dead code doesn't even mention x, and it appears
after the printing! What is the role of show x, which doesn't do anything?
Exercises: what is the significance of the monadic bind to x? Why
can't we replace it with let x = undefined?
[Significant hint, don't look at it]
Such a behavior always occurs when we have HM polymorphism restriction
and some sort of non-parametricity -- coupled with default rules or
overlapping instances or some other ways of resolving overloading. All
these features are essential (type-classes are significant,
defaulting is part of the standard and is being used more and more).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's type inference considered harmful
Actually, both examples show that the problem isn't type inference, it's
defaulting mechanism.
Отправлено с iPhone
Jul 17, 2012, в 12:46, o...@okmij.org написал(а):
1. Haskell's type inference is NON-COMPOSITIONAL!
Yes, it is -- and there are many examples of it. Here is an example
which has nothing to do with MonomorphismRestriction or numeric
literals
{-# LANGUAGE ExtendedDefaultRules #-}
class C a where
m :: a - Int
instance C () where
m _ = 1
instance C Bool where
m _ = 2
main = do
x - return undefined
let y = x
print . fst $ (m x, show x)
-- let dead = if False then not y else True
return ()
The program prints 1. If you uncomment the (really) dead code, it will
print 2. Why? The dead code doesn't even mention x, and it appears
after the printing! What is the role of show x, which doesn't do anything?
Exercises: what is the significance of the monadic bind to x? Why
can't we replace it with let x = undefined?
[Significant hint, don't look at it]
Such a behavior always occurs when we have HM polymorphism restriction
and some sort of non-parametricity -- coupled with default rules or
overlapping instances or some other ways of resolving overloading. All
these features are essential (type-classes are significant,
defaulting is part of the standard and is being used more and more).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-greedy match in Text.Regx.Posix
* C K Kashyap ckkash...@gmail.com [2012-07-17 13:31:05+0530] I was exploring Text.Regex.Posix and found that I was not able to do a non-greedy match by modifying the quantifier with a ?. How can I achieve non-greedy match in Text.Regex.Posix? POSIX regular expressions semantics doesn't have a notion of a greedy/non-greedy match. Use an engine that implements Perl semantics if you need one. Refer to [1] for more detail. [1]: http://www.haskell.org/haskellwiki/Regular_expressions#.28apple.7Corange.29 -- Roman I. Cheplyaka :: http://ro-che.info/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-greedy match in Text.Regx.Posix
Thanks Roman, I guess I better invest my time in Parsec then :) Regards, Kashyap On Tue, Jul 17, 2012 at 5:05 PM, Roman Cheplyaka r...@ro-che.info wrote: * C K Kashyap ckkash...@gmail.com [2012-07-17 13:31:05+0530] I was exploring Text.Regex.Posix and found that I was not able to do a non-greedy match by modifying the quantifier with a ?. How can I achieve non-greedy match in Text.Regex.Posix? POSIX regular expressions semantics doesn't have a notion of a greedy/non-greedy match. Use an engine that implements Perl semantics if you need one. Refer to [1] for more detail. [1]: http://www.haskell.org/haskellwiki/Regular_expressions#.28apple.7Corange.29 -- Roman I. Cheplyaka :: http://ro-che.info/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hackage compile failure with QuickCheck 2.5
[This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.] I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is: [13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o ) Test/QuickCheck/All.hs:15:1: Bad interface file: /usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH The full log file is at (search for Something is a miss in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4 Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package. Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency. I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.) -Levent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
Dear Levent, I think this [1] could be related. Regards, Alexander Foremny PS. Sent this to Levent directly. Here's a copy for the mailing list. Sorry for the noise. [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html -- Forwarded message -- From: Alexander Foremny alexanderfore...@gmail.com Date: 2012/7/17 Subject: Re: [Haskell-cafe] hackage compile failure with QuickCheck 2.5 To: Levent Erkok erk...@gmail.com Dear Levent, I think this [1] could be related. Regards, Alexander Foremny [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html 2012/7/17 Levent Erkok erk...@gmail.com: [This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.] I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is: [13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o ) Test/QuickCheck/All.hs:15:1: Bad interface file: /usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH The full log file is at (search for Something is a miss in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4 Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package. Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency. I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.) -Levent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
Thanks Alexander. However, I'm not sure how to use the workaround described so I can get hackage to properly compile my package. It sounds like I have to add a template-haskell = 2.7.0.0 dependency to my own cabal file, which sounds like the wrong thing to do in the long-run. Is there something that can be done on the hackage/ghc side to avoid this issue? Or something less drastic than adding a template-haskell dependency on my own package's cabal file? Thanks, -Levent. On Tue, Jul 17, 2012 at 7:31 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Dear Levent, I think this [1] could be related. Regards, Alexander Foremny PS. Sent this to Levent directly. Here's a copy for the mailing list. Sorry for the noise. [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html -- Forwarded message -- From: Alexander Foremny alexanderfore...@gmail.com Date: 2012/7/17 Subject: Re: [Haskell-cafe] hackage compile failure with QuickCheck 2.5 To: Levent Erkok erk...@gmail.com Dear Levent, I think this [1] could be related. Regards, Alexander Foremny [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html 2012/7/17 Levent Erkok erk...@gmail.com: [This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.] I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is: [13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o ) Test/QuickCheck/All.hs:15:1: Bad interface file: /usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH The full log file is at (search for Something is a miss in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4 Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package. Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency. I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.) -Levent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-greedy match in Text.Regx.Posix
On Tue, Jul 17, 2012 at 9:54 AM, C K Kashyap ckkash...@gmail.com wrote: I guess I better invest my time in Parsec then :) That's certainly more Haskelly... but it's often possible to rephrase a regexp in POSIX ERE language without using the non-greedy PCREism. What exactly are you trying to match / what is your PCRE regexp? -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
Which package are you trying to build? Is it a local package that fails to build or something on Hackage? Its .cabal file or at least full dependencies would be of interest. Regards, Alexander Foremny 2012/7/17 Levent Erkok erk...@gmail.com: Thanks Alexander. However, I'm not sure how to use the workaround described so I can get hackage to properly compile my package. It sounds like I have to add a template-haskell = 2.7.0.0 dependency to my own cabal file, which sounds like the wrong thing to do in the long-run. Is there something that can be done on the hackage/ghc side to avoid this issue? Or something less drastic than adding a template-haskell dependency on my own package's cabal file? Thanks, -Levent. On Tue, Jul 17, 2012 at 7:31 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Dear Levent, I think this [1] could be related. Regards, Alexander Foremny PS. Sent this to Levent directly. Here's a copy for the mailing list. Sorry for the noise. [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html -- Forwarded message -- From: Alexander Foremny alexanderfore...@gmail.com Date: 2012/7/17 Subject: Re: [Haskell-cafe] hackage compile failure with QuickCheck 2.5 To: Levent Erkok erk...@gmail.com Dear Levent, I think this [1] could be related. Regards, Alexander Foremny [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html 2012/7/17 Levent Erkok erk...@gmail.com: [This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.] I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is: [13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o ) Test/QuickCheck/All.hs:15:1: Bad interface file: /usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH The full log file is at (search for Something is a miss in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4 Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package. Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency. I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.) -Levent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
Dear Levent, unfortunately I am at a loss here. As far as I understand it this should be fixed in QuickCheck's .cabal file or on Hackage. But I am not experienced enough to decide. You best wait for someone else to comment on this. Depending on template-haskell in your .cabal file is not the way to go as far as I understand it. But maybe it's a possible work-around in case you depend on the package being available on Hackage timely. Regards, Alexander Foremny 2012/7/17 Levent Erkok erk...@gmail.com: It builds fine locally on my box; but not on hackage. Here's the page: http://hackage.haskell.org/package/sbv-2.2 Thanks for looking into this Alexander, I appreciate your help. -Levent. On Tue, Jul 17, 2012 at 9:09 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Which package are you trying to build? Is it a local package that fails to build or something on Hackage? Its .cabal file or at least full dependencies would be of interest. Regards, Alexander Foremny 2012/7/17 Levent Erkok erk...@gmail.com: Thanks Alexander. However, I'm not sure how to use the workaround described so I can get hackage to properly compile my package. It sounds like I have to add a template-haskell = 2.7.0.0 dependency to my own cabal file, which sounds like the wrong thing to do in the long-run. Is there something that can be done on the hackage/ghc side to avoid this issue? Or something less drastic than adding a template-haskell dependency on my own package's cabal file? Thanks, -Levent. On Tue, Jul 17, 2012 at 7:31 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Dear Levent, I think this [1] could be related. Regards, Alexander Foremny PS. Sent this to Levent directly. Here's a copy for the mailing list. Sorry for the noise. [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html -- Forwarded message -- From: Alexander Foremny alexanderfore...@gmail.com Date: 2012/7/17 Subject: Re: [Haskell-cafe] hackage compile failure with QuickCheck 2.5 To: Levent Erkok erk...@gmail.com Dear Levent, I think this [1] could be related. Regards, Alexander Foremny [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html 2012/7/17 Levent Erkok erk...@gmail.com: [This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.] I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is: [13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o ) Test/QuickCheck/All.hs:15:1: Bad interface file: /usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH The full log file is at (search for Something is a miss in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4 Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package. Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency. I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.) -Levent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
With ghc 7.4.1, cabal-install 0.13.3 and Cabal 1.14.0, % cabal install --avoid-reinstalls sbv-2.2 fails to find a plan without reinstalls, and recommends --solver=modular. % cabal install --solver=modular --avoid-reinstalls sbv-2.2 reinstalls template-haskell-2.6.0.0, which breaks the GHC installation. I've added the suggested --constraint='template-haskell==2.7.0.0' option as a workaround, but it seems the --avoid-reinstalls option is being ignored. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
Thanks Alexander.. Here's the shocker: I just checked that page again ( http://hackage.haskell.org/package/sbv) and now it's mysteriously fine! Hackage must've recompiled the package somehow. Someone watching this thread must've fixed something on the server and triggered a new compile. While I'm happy the problem is now gone, the mystery behind the hackage recompile remains.. Maybe someone can shed some light on how hackage goes about managing the uploads. -Levent. On Tue, Jul 17, 2012 at 9:43 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Dear Levent, unfortunately I am at a loss here. As far as I understand it this should be fixed in QuickCheck's .cabal file or on Hackage. But I am not experienced enough to decide. You best wait for someone else to comment on this. Depending on template-haskell in your .cabal file is not the way to go as far as I understand it. But maybe it's a possible work-around in case you depend on the package being available on Hackage timely. Regards, Alexander Foremny 2012/7/17 Levent Erkok erk...@gmail.com: It builds fine locally on my box; but not on hackage. Here's the page: http://hackage.haskell.org/package/sbv-2.2 Thanks for looking into this Alexander, I appreciate your help. -Levent. On Tue, Jul 17, 2012 at 9:09 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Which package are you trying to build? Is it a local package that fails to build or something on Hackage? Its .cabal file or at least full dependencies would be of interest. Regards, Alexander Foremny 2012/7/17 Levent Erkok erk...@gmail.com: Thanks Alexander. However, I'm not sure how to use the workaround described so I can get hackage to properly compile my package. It sounds like I have to add a template-haskell = 2.7.0.0 dependency to my own cabal file, which sounds like the wrong thing to do in the long-run. Is there something that can be done on the hackage/ghc side to avoid this issue? Or something less drastic than adding a template-haskell dependency on my own package's cabal file? Thanks, -Levent. On Tue, Jul 17, 2012 at 7:31 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Dear Levent, I think this [1] could be related. Regards, Alexander Foremny PS. Sent this to Levent directly. Here's a copy for the mailing list. Sorry for the noise. [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html -- Forwarded message -- From: Alexander Foremny alexanderfore...@gmail.com Date: 2012/7/17 Subject: Re: [Haskell-cafe] hackage compile failure with QuickCheck 2.5 To: Levent Erkok erk...@gmail.com Dear Levent, I think this [1] could be related. Regards, Alexander Foremny [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html 2012/7/17 Levent Erkok erk...@gmail.com: [This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.] I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is: [13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o ) Test/QuickCheck/All.hs:15:1: Bad interface file: /usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH The full log file is at (search for Something is a miss in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4 Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package. Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency. I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.) -Levent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
Ah, that explains why the hackage page mysteriously got fixed. Thanks for looking into this Ross. It still feels like this'll start biting more folks down the road. I've created the following cabal ticket so it can be tracked: https://github.com/haskell/cabal/issues/978 However, my understanding of the problem is rather incomplete; please feel free to add comments to the ticket. -Levent. On Tue, Jul 17, 2012 at 10:26 AM, Ross Paterson r...@soi.city.ac.uk wrote: With ghc 7.4.1, cabal-install 0.13.3 and Cabal 1.14.0, % cabal install --avoid-reinstalls sbv-2.2 fails to find a plan without reinstalls, and recommends --solver=modular. % cabal install --solver=modular --avoid-reinstalls sbv-2.2 reinstalls template-haskell-2.6.0.0, which breaks the GHC installation. I've added the suggested --constraint='template-haskell==2.7.0.0' option as a workaround, but it seems the --avoid-reinstalls option is being ignored. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] A riddle...
On Mon, 16 Jul 2012, Felipe Almeida Lessa wrote: On Mon, Jul 16, 2012 at 12:33 PM, Vo Minh Thu not...@gmail.com wrote: It seems like the infered type (and thus bounds) is different when you force the result to be a Color or not. Just give explicit type signatures and conversion functions. Actually, just *always* give explicit type signatures. Additionally, always compile with '-Wall' and follow the warnings. This way GHC will also warn about missing type signatures and it will even suggest type signatures. (and use haskell-cafe for riddles, please :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Criterion setup/teardown functions?
Is there anything in Criterion that allows for a benchmark to run some code before or after the thing that it's timing? As an example, I'd like to time a bunch of database inserts, but beforehand I want to create the target table, and afterwards I'd like to delete it. I don't really care to have the time spent on the create/delete recorded in the test run's timing, if that's possible to do. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Criterion setup/teardown functions?
On 17 July 2012 20:45, tsuraan tsur...@gmail.com wrote: Is there anything in Criterion that allows for a benchmark to run some code before or after the thing that it's timing? As an example, I'd like to time a bunch of database inserts, but beforehand I want to create the target table, and afterwards I'd like to delete it. I don't really care to have the time spent on the create/delete recorded in the test run's timing, if that's possible to do. See the second argument of defaultMainWith http://hackage.haskell.org/packages/archive/criterion/0.6.0.0/doc/html/Criterion-Main.html#v:defaultMainWith. The Criterion monad supports running arbitrary IO actions via liftIO. / Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the surefire way to handle all exceptions and make sure the program doesn't fail?
On 07/17/2012 08:34 AM, Yifan Yu wrote: First of all, apologise if the question is too broad. The background goes like this: I've implemented a server program in Haskell for my company intended to replace the previous one written in C which crashes a lot (and btw the technology of the company is exclusively C-based). When I chose Haskell I promised my manager (arrogantly - I actually made a bet with him), it won't crash. Now it has been finished (with just a few hundred LOC), and my test shows that it is indeed very stable. But by looking at the code again I'm a little worried, since I'm rather new to exception handling and there're many networking-related functions in the program. I was tempted to catch (SomeException e) at the very top-level of the program and try to recursively call main to restart the server in case of any exception being thrown, but I highly doubt that is the correct and idiomatic way. There are also a number of long-running threads launched from the main thread, and exceptions thrown from these threads can't be caught by the top-level `catch' in the main thread. My main function looks like this: [--snip--] I find that I can't tell whether a function will throw any exception at all, or what exceptions will be thrown, by looking at their documentation. I can only tell if I browse the source code. So the question is, how can I determine all the exceptions that can be thrown by a given function? Look at its source. And what is the best way to handle situations like this, with both the long-running threads and main thread need to be restarted whenever exceptions happen. The most robust way is probably to use a completely independent supervisor program, e.g. upstart, systemd, runit, etc. These usually have facilities for restarting the supervised program, and a rate limit on exactly how often to try that (over a given period of time). These *won't* work for a program that's deadlocked because an important thread has died. For that you'll need either a watchdog (external) or an in-program mechanism for supervised threads which can catch any and all exceptions and restart threads as necessary. This tends to very domain-specific, but you might take some inspiration for the way supervisor hierarchies work in the actor model. Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the surefire way to handle all exceptions and make sure the program doesn't fail?
On 17 July 2012 22:10, Bardur Arantsson s...@scientician.net wrote: On 07/17/2012 08:34 AM, Yifan Yu wrote: I can only tell if I browse the source code. So the question is, how can I determine all the exceptions that can be thrown by a given function? Look at its source. Not sure that's the most productive comment. ;-P ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the surefire way to handle all exceptions and make sure the program doesn't fail?
On 07/17/2012 10:17 PM, Christopher Done wrote: On 17 July 2012 22:10, Bardur Arantsson s...@scientician.net wrote: On 07/17/2012 08:34 AM, Yifan Yu wrote: I can only tell if I browse the source code. So the question is, how can I determine all the exceptions that can be thrown by a given function? Look at its source. Not sure that's the most productive comment. ;-P Well, it's either that or the documentation, and if you want to be *really* sure... (I did realize that the OP did mention looking at the source, I just thought I'd confirm. I hope it didn't come out snarky -- I certainly didn't intend it to.) Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Criterion setup/teardown functions?
See the second argument of defaultMainWith http://hackage.haskell.org/packages/archive/criterion/0.6.0.0/doc/html/Criterion-Main.html#v:defaultMainWith. the prep argument is run before the entire suite is run (i.e. once per criterion main invocation); I'm looking for some way to run code before and after each function being benchmarked (and different code around different functions being benchmarked). It looks like criterion is fairly hard-wired to time everything that is done to run a test, so I guess the answer to my question is a straightforward no :) I think I'd have to modify the Benchmarkable typeclass to have a setup and teardown in order to do what I want. Maybe I'll give that a shot. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the surefire way to handle all exceptions and make sure the program doesn't fail?
Hello there Yifan, exception handling should be done on a per-context basis, where the developer establishes the notion of context. Most of the time this boils down to releasing resources: forkIO (doStuffWith h `finally` hClose h) In more complicated scenarios, where you actually need to /handle/ the exception you should probably wrap some control concept around it. There are many options. You could just catch and handle the exception. Other options include a resumable monad (like monad-coroutine) that brings everything back into a consistent state. Exception handling is convenient in Haskell. You should probably just try to enforce some of the exception cases by using the server in a wrong way. Close the connection prematurely or send Unix signals. Note that you need to handle signals separately. In particular by default a SIGPIPE, which can in fact be thrown by the networking system, needs to be ignored: import System.Posix.Signal main :: IO () main = withSocketsDo $ do installHandler sigPIPE Ignore Nothing Finally for both efficiency and safety make use of a stream processing abstraction like conduit, enumerator or pipes. Greets, Ertugrul Yifan Yu yvi...@gmail.com wrote: First of all, apologise if the question is too broad. The background goes like this: I've implemented a server program in Haskell for my company intended to replace the previous one written in C which crashes a lot (and btw the technology of the company is exclusively C-based). When I chose Haskell I promised my manager (arrogantly - I actually made a bet with him), it won't crash. Now it has been finished (with just a few hundred LOC), and my test shows that it is indeed very stable. But by looking at the code again I'm a little worried, since I'm rather new to exception handling and there're many networking-related functions in the program. I was tempted to catch (SomeException e) at the very top-level of the program and try to recursively call main to restart the server in case of any exception being thrown, but I highly doubt that is the correct and idiomatic way. There are also a number of long-running threads launched from the main thread, and exceptions thrown from these threads can't be caught by the top-level `catch' in the main thread. My main function looks like this: main :: IO () main = withSocketsDo $ do sCameraU - socketNewPassive False 6000 sStunU - socketNewPassive False 3478 sCmdT- socketNewPassive True 7000 mvarCam - newMVar M.empty mvarLog - newMVar [] forkIO $ regCamera sCameraU mvarCam mvarLog forkIO $ updCamera mvarCam mvarLog forkIO $ stun sCameraU sStunU mvarCam mvarLog listen sCmdT 128 processCmd sCmdT mvarCam mvarLog sClose sCameraU sClose sStunU sClose sCmdT I find that I can't tell whether a function will throw any exception at all, or what exceptions will be thrown, by looking at their documentation. I can only tell if I browse the source code. So the question is, how can I determine all the exceptions that can be thrown by a given function? And what is the best way to handle situations like this, with both the long-running threads and main thread need to be restarted whenever exceptions happen. -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
Cabal doesn't play well with version constraints on the template-haskell package - it doesn't know it can't reinstall template-haskell. The workaround is to figure out why QuickCheck has version constraints on template-haskell and solve that problem in the QuickCheck package a different way - perhaps with CPP conditonal compilation macros - and then remove the problematic version constraints. On Jul 17, 2012 11:44 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Dear Levent, unfortunately I am at a loss here. As far as I understand it this should be fixed in QuickCheck's .cabal file or on Hackage. But I am not experienced enough to decide. You best wait for someone else to comment on this. Depending on template-haskell in your .cabal file is not the way to go as far as I understand it. But maybe it's a possible work-around in case you depend on the package being available on Hackage timely. Regards, Alexander Foremny 2012/7/17 Levent Erkok erk...@gmail.com: It builds fine locally on my box; but not on hackage. Here's the page: http://hackage.haskell.org/package/sbv-2.2 Thanks for looking into this Alexander, I appreciate your help. -Levent. On Tue, Jul 17, 2012 at 9:09 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Which package are you trying to build? Is it a local package that fails to build or something on Hackage? Its .cabal file or at least full dependencies would be of interest. Regards, Alexander Foremny 2012/7/17 Levent Erkok erk...@gmail.com: Thanks Alexander. However, I'm not sure how to use the workaround described so I can get hackage to properly compile my package. It sounds like I have to add a template-haskell = 2.7.0.0 dependency to my own cabal file, which sounds like the wrong thing to do in the long-run. Is there something that can be done on the hackage/ghc side to avoid this issue? Or something less drastic than adding a template-haskell dependency on my own package's cabal file? Thanks, -Levent. On Tue, Jul 17, 2012 at 7:31 AM, Alexander Foremny alexanderfore...@gmail.com wrote: Dear Levent, I think this [1] could be related. Regards, Alexander Foremny PS. Sent this to Levent directly. Here's a copy for the mailing list. Sorry for the noise. [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html -- Forwarded message -- From: Alexander Foremny alexanderfore...@gmail.com Date: 2012/7/17 Subject: Re: [Haskell-cafe] hackage compile failure with QuickCheck 2.5 To: Levent Erkok erk...@gmail.com Dear Levent, I think this [1] could be related. Regards, Alexander Foremny [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html 2012/7/17 Levent Erkok erk...@gmail.com: [This message is more appropriate for a hackage mailing list I presume, but that doesn't seem to exist. Let me know if there's a better place to send it.] I'm having a hackage compile failure for a newly uplodaded package that has a QuickCheck 2.5 dependence. The error message is: [13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, dist/build/Test/QuickCheck/All.o ) Test/QuickCheck/All.hs:15:1: Bad interface file: /usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH The full log file is at (search for Something is a miss in it): http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4 Needless to say, I don't see this problem when I compile this package at home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage has a successfully compiled QuickCheck 2.5 package. Could it be something related to the particular cabal/ghc installation on the hackage server? In particular, I don't understand why it picks template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I can see, QuickCheck doesn't put an upper limit on its template haskell version dependency. I'd appreciate any pointers with this. (Googling and questions on the #haskell irc channel didn't help much, unfortunately.) -Levent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
On Wed, Jul 18, 2012 at 12:14:12AM +0100, Antoine Latter wrote: Cabal doesn't play well with version constraints on the template-haskell package - it doesn't know it can't reinstall template-haskell. The workaround is to figure out why QuickCheck has version constraints on template-haskell and solve that problem in the QuickCheck package a different way - perhaps with CPP conditonal compilation macros - and then remove the problematic version constraints. QuickCheck's constraint is template-haskell = 2.4, which doesn't explain why cabal wanted to install 2.6.0.0 when 2.7.0.0 was already present. Also, I'd expect --avoid-reinstalls to stop it reinstalling anything, but apparently it doesn't do that with the modular solver. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] stripSuffix
Hi all -- Pardon me if this has been answered before: how come there's a stripPrefix in Data.List, but no matching stripSuffix? Thanks! Alvaro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] stripSuffix
On Tue, Jul 17, 2012 at 8:33 PM, Alvaro Gutierrez radi...@google.comwrote: Pardon me if this has been answered before: how come there's a stripPrefix in Data.List, but no matching stripSuffix? Probably because prefixes are easier to do, given the nature of singly linked lists. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the surefire way to handle all exceptions and make sure the program doesn't fail?
On Wed, Jul 18, 2012 at 4:10 AM, Bardur Arantsson s...@scientician.netwrote: The most robust way is probably to use a completely independent supervisor program, e.g. upstart, systemd, runit, etc. These usually have facilities for restarting the supervised program, and a rate limit on exactly how often to try that (over a given period of time). These *won't* work for a program that's deadlocked because an important thread has died. For that you'll need either a watchdog (external) or an in-program mechanism for supervised threads which can catch any and all exceptions and restart threads as necessary. This tends to very domain-specific, but you might take some inspiration for the way supervisor hierarchies work in the actor model. Hi Bardur, the supervised threads sounds like a good approach for me. Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the surefire way to handle all exceptions and make sure the program doesn't fail?
On Wed, Jul 18, 2012 at 7:05 AM, Ertugrul Söylemez e...@ertes.de wrote: exception handling should be done on a per-context basis, where the developer establishes the notion of context. Most of the time this boils down to releasing resources: forkIO (doStuffWith h `finally` hClose h) Hello Ertugrul, Agreed, although sometimes I just want to be lazy and catch any exception and see what it is in the top-level context :-) In more complicated scenarios, where you actually need to /handle/ the exception you should probably wrap some control concept around it. There are many options. You could just catch and handle the exception. Other options include a resumable monad (like monad-coroutine) that brings everything back into a consistent state. Finally for both efficiency and safety make use of a stream processing abstraction like conduit, enumerator or pipes. Thank you for these interesting pointers, I'll look into them later. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] stripSuffix
On 18/07/2012, at 12:37 PM, Brandon Allbery wrote: On Tue, Jul 17, 2012 at 8:33 PM, Alvaro Gutierrez radi...@google.com wrote: Pardon me if this has been answered before: how come there's a stripPrefix in Data.List, but no matching stripSuffix? Probably because prefixes are easier to do, given the nature of singly linked lists. Here are two other possible reasons. It's not just easier, stripPrefix pfx lst is *possible* as long as pfx is finite, even when lst is infinite. The same would not be true of a suffix stripper. It's so easy to write stripSuffix sfx lst = case stripPrefix (reverse sfx) (reverse lst) of Nothing - Nothing Just ys - Just (reverse ys) I can think of two cases where I'd want something like this. One is manipulating file extensions, where I'd want to use System.FilePath.splitExtension or something like that anyway. The other is suffix stripping for text processing, where I'd want to use a trie to match a whole lot of possible suffixes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] stripSuffix
On Tue, Jul 17, 2012 at 11:34 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: Here are two other possible reasons. It's not just easier, stripPrefix pfx lst is *possible* as long as pfx is finite, even when lst is infinite. The same would not be true of a suffix stripper. Isn't this the case with isSuffixOf, though? And yet it's there along with isPrefixOf... It's so easy to write stripSuffix sfx lst = case stripPrefix (reverse sfx) (reverse lst) of Nothing - Nothing Just ys - Just (reverse ys) Sure, it's not difficult to write such a function; the issue is the asymmetry (and thus, broken user expectations) based on the rest of the library. I can think of two cases where I'd want something like this. One is manipulating file extensions, where I'd want to use System.FilePath.splitExtension or something like that anyway. The other is suffix stripping for text processing, where I'd want to use a trie to match a whole lot of possible suffixes. For what it's worth, there are a lot of other cases (outside of file path handling) in which I've found it useful. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: hackage compile failure with QuickCheck 2.5
Hi. QuickCheck's constraint is template-haskell = 2.4, which doesn't explain why cabal wanted to install 2.6.0.0 when 2.7.0.0 was already present. Also, I'd expect --avoid-reinstalls to stop it reinstalling anything, but apparently it doesn't do that with the modular solver. Assuming the examples you gave are the ones that Hackage actually uses: Is it necessary that Hackage uses an unreleased and older version of cabal-install? I can't really tell right now what the differences between 0.13.3 and 0.14.0 are, but clearly, if the modular solver isn't the default, then there still are significant differences. AFAIK --avoid-reinstalls is completely ignored by the old solver, but *not* by the modular solver. For me, 2.6.0.0 is picked with --avoid-reinstalls *because* 2.7.0.0 is already present, and 2.6.0.0 isn't. In concrete terms, with Cabal-1.14.0, cabal-install-0.14.0 and a ghc-7.4.1-based Haskell Platform installation without further packages: $ cabal install --dry-run sbv Resolving dependencies... In order, the following would be installed: containers-0.5.0.0 (new version) mtl-2.1.2 (new version) strict-concurrency-0.2.4.1 (new package) syb-0.3.7 (new version) template-haskell-2.7.0.0 (reinstall) changes: containers-0.4.2.1 - 0.5.0.0 QuickCheck-2.5 (new version) sbv-2.2 (new package) Warning: The following packages are likely to be broken by the reinstalls: ghc-7.4.1 haddock-2.10.0 QuickCheck-2.4.2 haskell-platform-2012.2.0.0 Use --force-reinstalls if you want to install anyway. $ cabal install --dry-run sbv --avoid-reinstalls -v Reading available packages... Choosing modular solver. Resolving dependencies... In order, the following would be installed: containers-0.5.0.0 (new version) mtl-2.1.2 (new version) strict-concurrency-0.2.4.1 (new package) syb-0.3.7 (new version) template-haskell-2.6.0.0 (new version) QuickCheck-2.5 (new version) sbv-2.2 (new package) I haven't had time to thoroughly look at this problem, but it currently seems to me like it's triggered by containers-0.5.0.0 and has nothing to do with QuickCheck. The containers package is a dependency of template-haskell. So if containers is upgraded to 0.5, then template-haskell-2.7.0.0 would have to be reinstalled. With --avoid-reinstalls, cabal-install will pick an older template-haskell, not knowing that this will lead to a failure at build time. There's really no other chance, because sbv-2.2 seems to depend on containers-0.5.0.0. With containers being a dependency of GHC core libraries such as template-haskell, there isn't currently a good option to use containers-0.5.0.0 with ghc-7.4. Using --avoid-reinstalls blindly or as a default flag is also unfortunately not a good idea in general. There are simply too many cases where installing older versions of packages (which is often the only thing that helps) is not really the solution you want. That's also the reason why it's not enabled by default. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
