Re: [Haskell-cafe] Re: ANNOUNCE: GotoT-transformers version 1.0
On 9/11/10 10:36 PM, Ertugrul Soeylemez wrote: It should print the string, if the computation isn't aborted, i.e. if the last continuation, which you specify as an argument to runContT is reached. Greets, Ertugrul That's true, it just seems to me like at that point the spirit of the continuation monad is being violated since the final continuation is never actually called. That isn't necessarily a big deal, but it is the kind of behavior that could bite someone if they weren't aware or forgot about it. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Small question on concurrency
Hello Haskellers,
Having been pretty much impressed by Don Stewart's Practical Haskell
(http://donsbot.wordpress.com/2010/08/17/practical-haskell/), I
started to write a Haskell script to run maven jobs (yes, I know...).
In the course of undertaking this fantastic endeavour, I started to
use the System.Process.readProcessWithExitCode function, but following
the advice in the comment for this function, I rolled my own stuff and
ended up writing the following:
doRunMvnInIO pom args filters e
= do (Just inh, Just outh, Just errh, pid) -
createProcess (proc (maven e) ([-f, pom] ++ args)) { std_in =
CreatePipe,
std_out =
CreatePipe,
std_err =
CreatePipe }
waitQ - newEmptyMVar
mapM (printAndWait waitQ) [outh, errh]
hClose inh
-- wait on the process
waitForProcess pid
where
printAndWait waitQ hdl = do out - hGetContents hdl
forkIO (mapM (putStrLn) (filter filters
$ lines out) putMVar waitQ ())
takeMVar waitQ
hClose hdl
This is actually a rewrite of the following function:
doRunMvnInIO' pom args filters e
= do (Just inh, Just outh, Just errh, pid) -
createProcess (proc (maven e) ([-f, pom] ++ args)) { std_in =
CreatePipe,
std_out =
CreatePipe,
std_err =
CreatePipe }
waitQ - newEmptyMVar
mapM (printAndWait waitQ) [outh, errh] = mapM (\_ - takeMVar waitQ)
hClose inh
hClose outh
hClose errh
-- wait on the process
waitForProcess pid
where
printAndWait waitQ hdl = do out - hGetContents hdl
forkIO (mapM (putStrLn) (filter filters
$ lines out) putMVar waitQ ())
What surprised me is that I would expect the behaviour of the two
functions to be different:
- in doRunMvnInIO, I would expect stdout's content to be printed
before stderr, ie. the 2 threads are ordered because I call takeMVar
in between calls to forkIO
- in doRunMvnInIO', this is not true and both theads run concurrently.
but actually there does not seem to be a difference: printing is still
interleaved in both functions, AFAICT.
I would welcome any help on this.
Best regards,
Arnaud
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] benchmarking c/c++ and haskell
Hi,
I would like to benchmark C/C++ and Haskell code. The goal is to
improve the Haskell port[0] of smallpt[1].
To make sure my approach was reliable, I got the code of two programs
(one in C, the other in Haskell) from a post[2] by Don. The code is
reproduced below. When timing the execution of both program, I have a
4x difference. It is said on the blog the programs should have
similar performance.
I simply don't get the reason of such a difference. I've tried the
code on my Atom netbook and also on an older centrino machine. The
timing are similar (i.e. the C and Haskell program show 4x
difference). Both machines have GHC 6.12.1 on Linux.
Would you have an idea?
[0] http://hackage.haskell.org/package/smallpt-hs
[1] http://www.kevinbeason.com/smallpt/
[2]
http://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-c-working-at-a-high-altitude-for-low-level-performance/
$ gcc -O2 mean.c -omean-c
$ ghc --make -O2 mean.hs -o mean-hs
$ time ./mean-c 1e8
5000.50
real0m1.575s
user0m1.513s
sys 0m0.000s
$ time ./mean-hs 1e8
5000.5
real0m6.997s
user0m6.856s
sys 0m0.013s
-- file mean.hs
module Main where
import System.Environment
import Text.Printf
mean :: Double - Double - Double
mean n m = go 0 0 n
where
go :: Double - Int - Double - Double
go s l x | x m = s / fromIntegral l
| otherwise = go (s+x) (l+1) (x+1)
main = do
[d] - map read `fmap` getArgs
printf %f\n (mean 1 d)
/* file mean.c */
#include stdio.h
#include stdlib.h
int
main (int argc, char **argv)
{
double d = atof(argv[1]);
double n;
long a;
double b;
for (n = 1,
a = 0,
b = 0; n = d; b+=n,
n++,
a++)
;
printf(%f\n, b / a);
return 0;
}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] benchmarking c/c++ and haskell
Vo Minh Thu wrote: Hi, I would like to benchmark C/C++ and Haskell code. The goal is to improve the Haskell port[0] of smallpt[1]. To make sure my approach was reliable, I got the code of two programs (one in C, the other in Haskell) from a post[2] by Don. The code is reproduced below. When timing the execution of both program, I have a 4x difference. It is said on the blog the programs should have similar performance. I simply don't get the reason of such a difference. I've tried the code on my Atom netbook and also on an older centrino machine. The timing are similar (i.e. the C and Haskell program show 4x difference). Both machines have GHC 6.12.1 on Linux. Would you have an idea? The function floor :: Double - Int is surprisingly slow under GHC. (IIRC, it's implemented by converting Double - (Int, Integer) - Int, or something equally absurd.) Poking around GHC.Prim directly allows you to do the same operation much, much faster. I couldn't say exactly how much of a difference it makes, but I've had programs go from seconds to microseconds just by switching this. http://hackage.haskell.org/trac/ghc/ticket/2271 http://hackage.haskell.org/trac/ghc/ticket/1434 My solution was to do this: http://hackage.haskell.org/packages/archive/AC-Colour/1.1.3/doc/html/src/Data-Colour-FastFloor.html Uh... good luck! o_O (Of course, I could be speaking complete nonesense and this bug has since been fixed, or the cause of the slowness in smallpt is something else...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] benchmarking c/c++ and haskell
2010/9/12 Andrew Coppin andrewcop...@btinternet.com: Vo Minh Thu wrote: Hi, I would like to benchmark C/C++ and Haskell code. The goal is to improve the Haskell port[0] of smallpt[1]. To make sure my approach was reliable, I got the code of two programs (one in C, the other in Haskell) from a post[2] by Don. The code is reproduced below. When timing the execution of both program, I have a 4x difference. It is said on the blog the programs should have similar performance. I simply don't get the reason of such a difference. I've tried the code on my Atom netbook and also on an older centrino machine. The timing are similar (i.e. the C and Haskell program show 4x difference). Both machines have GHC 6.12.1 on Linux. Would you have an idea? The function floor :: Double - Int is surprisingly slow under GHC. (IIRC, it's implemented by converting Double - (Int, Integer) - Int, or something equally absurd.) Poking around GHC.Prim directly allows you to do the same operation much, much faster. I couldn't say exactly how much of a difference it makes, but I've had programs go from seconds to microseconds just by switching this. http://hackage.haskell.org/trac/ghc/ticket/2271 http://hackage.haskell.org/trac/ghc/ticket/1434 My solution was to do this: http://hackage.haskell.org/packages/archive/AC-Colour/1.1.3/doc/html/src/Data-Colour-FastFloor.html Uh... good luck! o_O Thanks for the tip. But I would really get the two little programs from Don's blog to have the same performance as advertised so that I can build from there. I have to make sure things are different for a good reason, not because of a flaw in my setup (which I assume it is since I can't even get those two to run in the same time). Thanks, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cost: (:) vs head
michael rice schrieb: Which of these would be more costly for a long list? f :: [Int] - [Int] f [x] = [x] f (x:xs) = x + (head xs) : f xs f :: [Int] - [Int] f [x] = [x] f (x:y:xs) = x + y : f (y:xs) What about empty lists? How about zipWith (+) xs (drop 1 xs ++ [0]) ? Since I often need to combine adjacent list elements, I have defined mapAdjacent in utility-ht. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cost: (:) vs head
Hi Henning, Thanks for the tip, I'll check it out. A related but more general question: on average, what's more efficient, pattern matching or function calls? Michael --- On Sun, 9/12/10, Henning Thielemann schlepp...@henning-thielemann.de wrote: From: Henning Thielemann schlepp...@henning-thielemann.de Subject: Re: [Haskell-cafe] Cost: (:) vs head To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Sunday, September 12, 2010, 8:47 AM michael rice schrieb: Which of these would be more costly for a long list? f :: [Int] - [Int] f [x] = [x] f (x:xs) = x + (head xs) : f xs f :: [Int] - [Int] f [x] = [x] f (x:y:xs) = x + y : f (y:xs) What about empty lists? How about zipWith (+) xs (drop 1 xs ++ [0]) ? Since I often need to combine adjacent list elements, I have defined mapAdjacent in utility-ht. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
Hi Paolo, Paolo Giarrusso wrote: - when recompiling a package with ABI changes, does cabal always update dependent packages? It never recompiles them. Recompilation should not be needed, because different versions of packages exports different symbols, so a package can never be linked against the wrong version of its dependency. However, see the following tickets: http://hackage.haskell.org/trac/hackage/ticket/701 http://hackage.haskell.org/trac/hackage/ticket/704 Interestingly, HTTP, directory, process, zip-archive were not reinstalled, which confirms that Cabal had reinstalled them before just because of an upgrade to the dependencies. I think you are misinterpreting this. When you asked cabal-install to install pandoc, it tried to make a consistent install plan for all its transitive dependencies. cabal-install will not touch a package which is not a transitive dependency of the package you request to be installed. Therefore, cabal-install will not touch Cabal if you ask it to install pandoc. To make a consistent install plan, cabal-install has to pick exactly one version number for each of the transitive dependencies, so that all version constraints of all transitive dependencies are fullfilled. For some reason, cabal-install picked old-locale-1.0.0.2 instead of the already installed old-locale-1.0.0.1, and newer versions of HTTP, directory etc. too. I think this is the bug: cabal-install should not be allowed to install old-locale, because doing so apparantly causes havoc. Looking at the inter-dependencies of pandoc's transitive dependencies, I do not see a reason to install a new version of a package instead of keeping the old. Maybe it's somehow related to the transition from base-3 to base-4? But I don't know how cabal-install decides which install plan to follow anyway. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
Hi Paolo, Paolo Giarrusso wrote: $ cabal install --dry cabal-install leksah-0.8.0.6 [... does not work ...] However, trying to install cabal-install and leksah separately works quite well. So do install them separately. cabal install p1 p2 is supposed to find a single consistent install plan for p1 and p2 and the transitive dependencies of either of them. This is useful if you plan to use p1 and p2 in a single project. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: Type families - how to resolve ambiguities?
Paolo,
The problem with mult is that k is not specified unambiguously. You either
need v to determine k (which is probably not what you want, at a guess), mult
to take a dummy argument that determines what k is:
[...]
or, to make Tensor a data family instead of a type family.
What is the difference making it work?
The problem is that in your definition of mult
mult :: Tensor k v v - v
you seem to expect the type v to be determined by the type of Tensor
you apply it to. However, since Tensor is not an injective type
functor, it does not uniquely determine the type v. It is possible
that there is a completely unrelated type instance for Tensor, for
different types k and v that is also equal to the type you apply mult
to.
If you make Tensor a data family, then the types k and v are uniquely
determined, because then it is an injective type functor.
However, it would make more sense to have it be a type family, without
the overhead of data (both in space and in typing).
You can make Tensor a data family and use newtype instances. As I
understand these, there should not be a space overhead. The only
overhead I would expect this to introduce is the extra newtype
constructor.
Is there a non-
hacky approach, without dummies and without making Tensor a data
family without a semantic need?
Without thinking about your problem domain, I have the impression that
you do have a semantic need, because you seem to expect your Tensor
type to uniquely determine at least the type v. If this is not the
case, you need a different solution.
Anyway, the below compiles fine with the following result:
*Main mult $ Tensor $ (V [(T [1] [2],3)] :: Vect Integer (TensorBasis
[Int] [Int]))
V [([1,2],3)]
{-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-}
{-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
data Vect k b = V [(b,k)] deriving (Eq,Show)
data TensorBasis a b = T a b deriving (Eq, Ord, Show)
data family Tensor k u v :: *
newtype instance Tensor k (Vect k a) (Vect k b) = Tensor (Vect k
(TensorBasis a b))
class Algebra k v where -- v is a k-algebra
unit :: k - v
mult :: Tensor k v v - v
instance Algebra Integer (Vect Integer [Int]) where
unit 0 = V []
unit x = V [([],x)]
mult (Tensor (V ts)) = V [(g++h,x) | (T g h, x) - ts]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
On Sun, Sep 12, 2010 at 15:30, Tillmann Rendel ren...@mathematik.uni-marburg.de wrote: Paolo Giarrusso wrote: $ cabal install --dry cabal-install leksah-0.8.0.6 [... does not work ...] However, trying to install cabal-install and leksah separately works quite well. So do install them separately. Yeah, I did, I was pointing out the behavior because it _looked_ like a bug. And while it's a feature, it is there to cater with another bug (see below). Indeed, nothing in this thread is an assistance request. cabal install p1 p2 is supposed to find a single consistent install plan for p1 and p2 and the transitive dependencies of either of them. This is useful if you plan to use p1 and p2 in a single project. Ahah! Then it's a feature. The need for consistency stems from a bug: in a tracker entry you linked to, http://hackage.haskell.org/trac/hackage/ticket/704, duncan argues that we also want to be able to do things like linking multiple versions of a Haskell package into a single application. If that were possible, cabal would solve my request by using Cabal 1.6 and 1.8 together - you can make that work if type-checking uses _versioned_ types (that's not discussed in bug #704 though). I believe, though, cabal should still try to avoid that unless needed or explicitly requested. Among other reasons, even after typechecking, Cabal 1.6 and 1.8 might interact differently with RealWorld, say through incompatible file formats. In that case, I would refrain from installing both, or Cabal 1.8 would have some imaginary Conflicts: Cabal-1.6 property (which exists for Debian packages). But I see that here, the only correct install plan implies a GHC upgrade via Cabal and Hackage, which should not happen without a warning, and should never be attempted until all fundamental problems we are discussing are solved. -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
On Sep 12, 2:51 am, wren ng thornton w...@freegeek.org wrote: On 9/11/10 3:43 PM, Daniel Fischer wrote: - is there a specification of which are the core packages? core as in *do not update*? Basically, what comes with GHC shouldn't be updated. Though I heard updating Cabal was okay. I tried updating Cabal once (recently) and it broke things in the same way. FWIW. My Cabal was upgraded and is alive, but the bugs we see don't make the upgrade reliable. Most variations of the trap I hit would have killed cabal, period. Some could have killed GHC. And even for my case, resurrecting my old friend Cabal after his attempted suicide was not for the faint-heart, and took much more time than letting him die and replacing him with some other friend, i.e. reinstalling from scratch the user packages - I just never allow my programmed friends to die, if I can avoid that. I value their liveness :-D. -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: GotoT-transformers version 1.0
On Sun, Sep 12, 2010 at 1:19 AM, Gregory Crosswhite gcr...@phys.washington.edu wrote: That's true, it just seems to me like at that point the spirit of the continuation monad is being violated since the final continuation is never actually called. That isn't necessarily a big deal, but it is the kind of behavior that could bite someone if they weren't aware or forgot about it. I guess you could newtype ConT to make GotoT, and then provide your own runner with `return` as the continuation, and then that detail doesn't escape. Or provide the `goto` combinator in the same module as a ContT runner which auto-passes a vacuous final continuation. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
Hi!
First, sorry for some confusion - I wanted to post further details
needed for the analysis in the mail I lost, and I had excluded them
from my summary to keep it short.
On Sun, Sep 12, 2010 at 15:26, Tillmann Rendel
ren...@mathematik.uni-marburg.de wrote:
Hi Paolo,
Paolo Giarrusso wrote:
- when recompiling a package with ABI changes, does cabal always
update dependent packages?
It never recompiles them. Recompilation should not be needed, because
different versions of packages exports different symbols, so a package can
never be linked against the wrong version of its dependency.
My problem was with reinstalling the same version of a package. Again,
sorry for the confusion (see above). cabal should then recompile (not
update, strictly speaking) dependent packages:
Recompiling the same version of a package does not always yield the
same result, ABI-wise.
The problem was an ABI difference between two compilation results for
old-time-1.0.0.2, one linked against old-locale-1.0.0.1, the other
against version 1.0.0.2 of the same package. The ABI difference was
_probably_ due to different cross-module inlining decisions: the
disappeared symbols were:
oldzmtimezm1zi0zi0zi2_SystemziTime_a149_{closure,info},
i.e. (I assume) old-time-1.0.0.2-System.Time.a149. That name is
generated by GHC during optimization, and my educated guess is that it
is exported to allow cross-module inlining. In particular, a149 is
mentioned in the .hi interface of old-time's System.Time - libs
dir/old-time-1.0.0.2/System/Time.hi
It thus _seems_ that the ABI of a module is a (pure) function of the
versions of all its (transitive) dependencies, and their compilation
options - in particular, the optimization options and the used
compiler version.
More formally, my conjecture is:
- let us represent package a depends on b as a = b, where a, b
are package names tagged with a version
- let =* be the transitive-reflexive closure of =
we need to compute:
DEPS(p) = {q | p =* q }
TAGGED_DEPS(p) = { (q, compilation_opts(q)) | q \in DEPS(p) }
where compilation_opts(q) are the compilation options used to compile package q.
Then, the ABI of a module is a pure function of TAGGED_DEPS(p), not
just of p. My experience proves at least that the ABI does not depend
just on p.
And since, after the discussion up-to-now, it turns out that this is
unexpected, I reported this as a bug:
http://hackage.haskell.org/trac/hackage/ticket/738
Another result of the above is that a mere cabal install --reinstall
-O2 FooPackage, recompiling the same version of FooPackage with -O2
instead of the default (-O1), requires recompiling all packages which
depends on (i.e. use symbols from) FooPackage; recompiling them
implies recompiling packages depending on them, and so on, in a
transitively closed way.
BINARY_LIBRARIES
A final result is that shipping Haskell libraries in binary form (i.e.
closed source libraries) is not supported without major changes. Not
that I care directly, but somebody might, especially since you choose
the BSD license over the GPL one. And fixing that might also make
package upgrades more sustainable, i.e. allowing to upgrade a
library while rebuilding less dependent modules. To ship a binary
library, one would need:
- disabling cross-module inlining when building the closed source
library, but that's not enough: one still needs to link to a specific
version of a package, because the version number is mangled into the
name, up to the 4th version level. That's inconvenient, because a
library can't benefit from a change affecting only the implementation,
and not the interface, of a library (e.g., a bugfix or a security
fix).
== On .NET, changes to the last version number must be
binary-compatible, so 1.0.0.1 and 1.0.0.2 are equivalent at link time,
and 1.0.0 and 1.0.1 are incompatible but can coexist.
== On ELF, for libraries which care (say glibc), each symbol is
available (with the same ABI) from a given library version onwards;
client binaries depend on at dynamic linking time on a library version
= the one they needed. An Hello World program, using no recent
functions, could thus be backportable even to an earlier version of
the C library. But I don't propose that, it requires enormous effort.
Most other libraries use a Scheme which is similar to the .NET one,
barring some big but superficial differences.
- resorting to full static linking, if that's supported; even then,
one can't statically link to the runtime system, and typechecking
needs to use versioned typenames.
/BINARY_LIBRARIES
However, see
the following tickets:
http://hackage.haskell.org/trac/hackage/ticket/701
http://hackage.haskell.org/trac/hackage/ticket/704
Had a look, thanks - but they do not apply here, the problem is with
Haskell symbols.
Interestingly, HTTP, directory, process, zip-archive were not
reinstalled, which confirms that Cabal had reinstalled them before
just because of an upgrade to the dependencies.
I think you are
Re: [Haskell-cafe] Disable LINE Pragma handling in GHC
Users may not want to edit the files directly, but they'll be happy to be able to open them with proper syntax highlighting, for example. JP On Sat, Sep 11, 2010 at 7:57 PM, Henning Thielemann schlepp...@henning-thielemann.de wrote: JP Moresmau schrieb: Hello fellow Haskellers, In EclipseFP we use the GHC API for IDE related stuff like syntax highlighting and code outlines. However, I ran into something funny yesterday: when a source file contains LINE pragmas ( http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/pragmas.html#line-pragma ), all the locations for tokens are changed to reflect the pragmas information. I thought that files that contain the LINE pragma usually are automatically generated files. Why would you want to edit or maintain such files in an IDE? -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] darcs in 2010: talk/video online
Dear Haskellers, Derek asked me if I could give a 5 minute talk at AngloHaskell last Friday about the Darcs project. It took an hour and a half. I've redone the talk on YouTube, basically just stepping through the slides and talking over them. It's about an hour long and you can watch it here: http://www.youtube.com/watch?v=iUytayyTGTU You may also prefer to just zoom through the slides yourself (about 10 minutes): http://prezi.com/is5nzudw8jxq/darcs-in-2010/ Many thanks to Derek for organising the AngloHaskell event and for thinking hard about how to make it work better! Thanks also to the Darcs hackers who did the actual work behind this talk, and to the user community for all your support and feedback. Eric PS: the talk segments are: 1. http://www.youtube.com/watch?v=iUytayyTGTU 2. http://www.youtube.com/watch?v=ZXjTmWD81JA 3. http://www.youtube.com/watch?v=1lXOD3fLwU8 4. http://www.youtube.com/watch?v=aueSoZShobo 5. http://www.youtube.com/watch?v=-JxJKMSRmBY 6. http://www.youtube.com/watch?v=zdImEqRmw7I -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow For a faster response, try +44 (0)1273 64 2905 or xmpp:ko...@jabber.fr (Jabber or Google Talk only) pgpFQGGAJlkYN.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
Hi Paolo, Paolo Giarrusso wrote: cabal install p1 p2 is supposed to find a single consistent install plan for p1 and p2 and the transitive dependencies of either of them. This is useful if you plan to use p1 and p2 in a single project. Ahah! Then it's a feature. The need for consistency stems from a bug: in a tracker entry you linked to, http://hackage.haskell.org/trac/hackage/ticket/704, duncan argues that we also want to be able to do things like linking multiple versions of a Haskell package into a single application. I think this is a slightly different matter. Consider a package pair, which defines an abstract datatype of pairs in version 1: module Pair (Pair, fst, snd, pair) where data Pair a b = Pair a b fst (Pair a b) = a snd (Pair a b) = b pair a b = Pair a b In version 2 of pair, the internal representation of the datatype is changed: module Pair (Pair, fst, snd, pair) where data Pair a b = Pair b a fst (Pair b a) = a snd (Pair b a) = b pair a b = Pair b a Now we have a package foo which depends on pair-1: module Foo (foo) where import Pair foo = pair 42 '?' And a package bar which depends on pair-2: module Bar (bar) where import Pair bar = fst Now, we write a program which uses both foo and bar: module Program where import Foo import Bar main = print $ bar $ foo Even with the technical ability to link all of foo, bar, pair-1 and pair-2 together, I don't see how this program could be reasonably compiled. Therefore, I think that the notion of consistent install plans is relevant semantically, not just to work around some deficiency in the linking system. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.Text performance problem
I experienced a following problem while dealing with some text processing.
I have a text and want to get the same text with parts enclosed into {} or
[] stripped away. Substituting them with a ' ' would also work.
Here is the code I wrote (T is Data.Text):
stripBrackets :: T.Text - T.Text
stripBrackets text = snd $ T.mapAccumL f 0 text where
f depth c = let
depth' = depth + d' c
c' | depth 0 || depth' 0 = ' '
| otherwise = c
in
(depth', c')
d' '{' = 1
d' '[' = 1
d' '}' = -1
d' ']' = -1
d' _ = 0
The only problem is that it takes about a minute to complete on 3GHz+
processor when text is a 30k chars long.
Any ideas how to improve this code?
--
Regards, Petr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: darcs in 2010: talk/video online
On Sun, Sep 12, 2010 at 19:33:56 +0100, Eric Kow wrote: PS: the talk segments are: I missed a segment! 1. http://www.youtube.com/watch?v=iUytayyTGTU 2. http://www.youtube.com/watch?v=ZXjTmWD81JA 3. http://www.youtube.com/watch?v=1lXOD3fLwU8 4. http://www.youtube.com/watch?v=aueSoZShobo 5. http://www.youtube.com/watch?v=emYcgR94RR0 -- missing segment 6. http://www.youtube.com/watch?v=-JxJKMSRmBY 7. http://www.youtube.com/watch?v=zdImEqRmw7I -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow For a faster response, try +44 (0)1273 64 2905 or xmpp:ko...@jabber.fr (Jabber or Google Talk only) pgpfjdD59CNRw.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Text performance problem
On Sunday 12 September 2010 21:23:50, Petr Prokhorenkov wrote:
I experienced a following problem while dealing with some text
processing.
I have a text and want to get the same text with parts enclosed into {}
or [] stripped away. Substituting them with a ' ' would also work.
Here is the code I wrote (T is Data.Text):
stripBrackets :: T.Text - T.Text
stripBrackets text = snd $ T.mapAccumL f 0 text where
f depth c = let
depth' = depth + d' c
c' | depth 0 || depth' 0 = ' '
| otherwise = c
in
(depth', c')
d' '{' = 1
d' '[' = 1
d' '}' = -1
d' ']' = -1
d' _ = 0
The only problem is that it takes about a minute to complete on 3GHz+
processor when text is a 30k chars long.
Any ideas how to improve this code?
First, is it intentional that
stripBrackets a]b[c] = a]b[c] and not a]b?
Also that it doesn't distinguish between the types of brackets, e.g.
stripBrackets {a] = ?
Of course, if you know that the text is properly bracketed, that's not
important.
Concerning the performance, it seems that mapAccumL actually has quadratic
complexity instead of linear because it doesn't get fused.
Ouch.
I think
stripBrackets :: T.Text - T.Text
stripBrackets text = T.concat $ go 0 text
where
go depth inp = case T.breakBy (`elem` {[]}) inp of
(pre,post) -
case T.uncons post of
Nothing - if depth 0
then [T.pack $ replicate (T.length pre)
' ']
else [pre]
Just (c,tl) -
let depth'
| c `elem` {[ = depth + 1
| otherwise = depth - 1
in (if depth 0
then T.pack (replicate (T.length pre) ' ')
else pre) :
T.pack (if depth 0 || depth' 0
then
else [c])
: go depth' tl
has the same semantics as your function. It's not blazingly fast either
(using String for that purpose is much faster), but it's orders of
magnitude faster than T.mapAccumL.
Note that it's easy to remove the parts enclosed in brackets instead of
replacing it by ' ' here.
--
Regards, Petr
Cheers,
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: ecu-0.0.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/11/10 13:46 , Henning Thielemann wrote: Would it be better to write canlib in a way that works on both Windows and Unix? Otherwise all packages that import canlib have to add this switch. The phrasing of the original request leads me to believe that this is outside of the OP's control. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyNWNoACgkQIn7hlCsL25U55ACgkDoFO8buGrzINsRowfF7+aZ4 LrcAoLeysSsP5jzhl92kpKFnHx5GwWTA =x2Bx -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/11/10 15:43 , Daniel Fischer wrote: On Saturday 11 September 2010 20:38:21, Paolo Giarrusso wrote: - is there a specification of which are the core packages? core as in *do not update*? Basically, what comes with GHC shouldn't be updated. Though I heard updating Cabal was okay. Some consistency would be nice; IIRC GHC refers to them as boot libraries. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyNWd0ACgkQIn7hlCsL25V/XgCePB0l/4kq3VGUgHlK7R5foRTh D2IAnj57oxPA2TGuiJQ+rHkZbVSP9aDB =FYF8 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Text performance problem
On Sun, Sep 12, 2010 at 12:23 PM, Petr Prokhorenkov prokhoren...@gmail.comwrote: I experienced a following problem while dealing with some text processing. Thanks for the report and the test case. There's nothing wrong with your code - read on for details. You ran into one of the few functions in Data.Text that I copied straight over from the list implementation due to it not being used often. Unfortunately, that implementation constructs a new Text value (using cons) on every iteration through the loop, and as you might expect that's very slow even on tiny inputs, as it has quadratic behaviour. I've rewritten both strict and lazy mapAccumL and mapAccumR to use as much of the stream fusion machinery as possible. (By the way, there's an interesting fact behind why those functions started out life as they did: you can't write mapAccum functions using only stream machinery, due to their types, and the strict code is more work to write if you can't use the stream machinery. In the early days it just wasn't worth writing the more complex variants of them, as I had more pressing performance concerns at the time.) Where the old version of mapAccumL caused your test case to take 5 seconds to process an 11KB file (ouch!), with the rewritten version, your code can process an 81MB file in the same amount of time, without any changes to your code, and that O(n^2) behaviour is gone :-) text 0.8.1.0 is now up on hackage, with the fix included. Enjoy! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Text performance problem
On Sun, Sep 12, 2010 at 10:06 PM, Bryan O'Sullivan b...@serpentine.com wrote: text 0.8.1.0 is now up on hackage, with the fix included. Enjoy! Wow! That was fast! =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Subcategories in Hackage
Hi, all! Now, with the approaching new Hackage server, I thought that to organize packages into subcategories would be useful. Categories like System or Text, with almost 200 packages, make more difficult to find what you want. Data category has currently 326 packages, many of them with very different roles. Perhaps, this is madness, but I wanted to read other opinions on this topic. -- Daniel Díaz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subcategories in Hackage
Perhaps, this is madness, but I wanted to read other opinions on this topic. Packages already have multiple tags, right? So how about a search box that uses ANDed tags (in addition to description etc), and a browsing interface where you can see tags of packages matching the current search, and click on one to AND it into the search? That might be easier than trying to fit everything into one hierarchy. Some packages can go in more than one place. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subcategories in Hackage
On 13 September 2010 11:37, Evan Laforge qdun...@gmail.com wrote: Perhaps, this is madness, but I wanted to read other opinions on this topic. Packages already have multiple tags, right? So how about a search box that uses ANDed tags (in addition to description etc), and a browsing interface where you can see tags of packages matching the current search, and click on one to AND it into the search? That might be easier than trying to fit everything into one hierarchy. Some packages can go in more than one place. Perhaps a better statement of what each tag actually represents so that people can better choose which tags fit their package. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subcategories in Hackage
El Lun, 13 de Septiembre de 2010, 3:37 am, Evan Laforge escribió: That might be easier than trying to fit everything into one hierarchy. Some packages can go in more than one place. I have not contradicted that. A package can go somewhere. For example: CAT. A * SUBCAT. A1 ** Pack. 1 * SUBCAT. A2 ** Pack. 2 ** Pack. 3 CAT. B * SUBCAT. B1 ** Pack. 4 ** Pack. 3 * SUBCAT. B2 ** Pack. 1 ** Pack. 5 Thanks for the opinion. -- Daniel Díaz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cleaning up threads
Hi! I run multiple threads where I would like that exception from any of them (and main) propagate to others but at the same time that they can gracefully cleanup after themselves (even if this means not exiting). I have this code to try, but cleanup functions (stop) are interrupted. How can I improve this code so that this not happen? module Test where import Control.Concurrent import Control.Exception import Control.Monad thread :: String - IO ThreadId thread name = do mainThread - myThreadId forkIO $ handle (throwTo mainThread :: SomeException - IO ()) $ -- I want that possible exception in start, stop or run is propagated to the main thread so that all other threads are cleaned up bracket_ start stop run where start = putStrLn $ name ++ started stop = forever $ putStrLn $ name ++ stopped -- I want that all threads have as much time as they need to cleanup after themselves (closing (IO) resources and similar), even if this means not dying run = forever $ threadDelay $ 10 * 1000 * 1000 run :: IO () run = do threadDelay $ 1000 * 1000 fail exit main :: IO () main = do bracket (thread foo) killThread $ \_ - bracket (thread bar) killThread $ \_ - bracket (thread baz) killThread (\_ - run) Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
