- Haskell-Cafe - Haskell.org

Load testing
by Tony Morris 29 Nov '10

29 Nov '10

Does there exist a package for convenient load-testing against a website? e.g. making lots of HTTP requests against a server, including timing, and collecting the results? -- Tony Morris http://tmorris.net/

3 2

Re: Template Haskell: exchanging information between 'splicers'
by jean-christophe mincke 29 Nov '10

29 Nov '10

Oleg, I am using GHC 6.12.3 Here a reproduction: in the file Template.hs proc () = runIO $ do runQ [|1+1|] proc' () = [|1+1|] In the file Main.hs i1 = $(proc ()) -- fails at compile time with "Segmentation fault/access violation in generated code". Maybe is it the expected behavior, I do not know. i2 = $(proc' ()) -- sucessfull i3 = proc() -- sucessful but proc is executed at "runtime" main = ... Hope it is clear enough otherwise let me know. Regards J-C On Mon, Nov 29, 2010 at 4:45 AM, <oleg(a)okmij.org> wrote: > > Hello! > > > But, please, correct me if I am wrong, in your example, the splicer are > > executed at run time and not at compile time. > > With TH, it becomes a bit difficult to tell what is exactly `compile > time'. One can say however that when the code is ready to be spliced > in at the top level, the IO actions in its splices must have been > completed. > > > I have modified your example to make it run at compile time and I get a > > (compile time) segmentation fault. > > As I mentioned, the code was specifically designed to cause something > like segmentation fault. Sneaking out free variables is definitely the > bad thing. The principle of exchanging data between splices (using > runQ/runIO) is valid and could be used for good things, too. > > I am wondering though what GHC version and command-line parameters are > you using? On my system. with GHC 6.10.3, I tried running the original > and modified code in GHCi and GHC (with and without -O2) and did not > get segmentation fault. Could you provide more details about your > system so to reproduce the segfault? I think Simon Peyton-Jones would > really like to know all that. > > Cheers, > Oleg >

1 0

DPH and GHC 7.0.1
by Gregory Propf 29 Nov '10

29 Nov '10

I was hoping to play around with Data.Parallel.Haskell (dph) but noticed that it seems to have been exiled from ghc 7.0.1 which I just installed. It also doesn't seem to be in cabal. Anybody know how to use dph with 7.0.1 or has it been abandoned or something?

5 4

Re: [Haskell] haskell.org downtime: Tuesday Nov 30th
by Henning Thielemann 28 Nov '10

28 Nov '10

Ian Lynagh schrieb: > We plan to have some haskell.org downtime on Tuesday Nov 30th, while we > migrate to the new server. Is there a simple way for me to get a local copy of the Wiki content? I have contributed to several articles and could rest more easily with a local backup before the server is migrated. :-)

1 0

ANNOUNCE: iteratee-compress 0.1.2
by Maciej Piechotka 28 Nov '10

28 Nov '10

Iteratee-compress provides compressing and decompressing enumerators including flushing. Currently only gzip is provided but at bzip and LZMA are planned. This is bug-fixing release Changes from previous version: - Fix infinite loop/segfault bug - Fix bug in which part of the output was lost - Support for iteratee 0.5 and 0.6 Next goals: - BZip support - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing? Regards

1 1

ANNOUNCE: iteratee-parsec 0.0.6
by Maciej Piechotka 28 Nov '10

28 Nov '10

Iteratee-parsec is a library which allows to have a parsec (3) parser in Iteratee monad. It contains 2 implementations: - John Lato's on public domain. It is based on monoid and design with short parsers in mind. - Mine on MIT. It is based on single-linked mutable list. It seems to be significantly faster for larger parsers - at least in some cases - but it requires a monad with references (such as for example IO or ST). The version 0.0.6 uses reference library. Regards

1 0

ANNOUNCE: iteratee-compress 0.1.2
by Maciej Piechotka 28 Nov '10

28 Nov '10

Iteratee-compress provides compressing and decompressing enumerators including flushing. Currently only gzip is provided but at bzip and LZMA are planned. This is bug-fixing release Changes from previous version: - Fix infinite loop/segfault bug - Fix bug in which part of the output was lost Next goals: - BZip support - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing? Regards

1 0

Return stack buffer vs Haskell compilers
by Florian Weimer 28 Nov '10

28 Nov '10

Are there any Haskell compilers which use a calling convention which is friendly to return stack buffers found in many modern CPUs? Such a calling convention uses CALL/RET pairs for function calls. Tail calls are implemented with JMP and may require shuffling the stack, including the return address, if the number of arguments passed on the stack differs between tail caller and callee. Such an approach means that the CPU can use the return stack buffer, which allows exact prediction of the jump target of the RET instruction (as long as the return stack buffer does not overflow). In contrast, if an indirect jump is used to implement RET, it enters the same prediction logic as any other indirect call, which is less precise and affects predicition of other indirect calls. This is especially important on the Intel Atom and VIA Nano CPUs, which are reported (Agner Fog, "The microarchitecture of Intel, AMD and VIA CPUs", last updated 2010-09-25) to have a return stack buffer, but a very simple indirect branch predictor which uses the last target as the next predicted target.

1 0

Why does cabal sdist still make tarballs with incorrect file modes?
by John D. Ramsdell 28 Nov '10

28 Nov '10

As I played with GHC 7.0.1, I noticed that Cabal sdist is still hosed. Since ten months ago, cabal sdist fails to preserve the file mode bits of the source files put into the tarball being generated (Ticket #627 reported by draconx). An executable shell script and a source file world readable both have a mode of 600 in the tarball. Does anyone know why this bug is difficult to fix? Why can't one revert to the code used in Cabal 1.6.0.1, which is know to work? John

1 0

Bulletproof resource management
by Florian Weimer 28 Nov '10

28 Nov '10

At least in my experience, in order to get proper resource management for things like file or database handles, you need both a close operation and a finalizer registered with the garbage collector. The former is needed so that you can create resources faster than the garbage collector freeing them. The latter is a safety net in cases where proper resource management is not follwoed (perhaps in GHCi). When the explicit close operation or the finalizer has been invoked, the object must somehow be disabled, so that further operations on it fail (otherwise, you might dereference a dangling pointer). What's the idom for implementing this in Haskell (or GHC)? It seems that a ForeignPtr cannot be written to (otherwise I'd change it to a null pointer when the resource is freed). It's also not possible to check if the finalizers have been run. Can the finalizers hold a reference to the object which in turn holds the ForeignPtr to be finalized? Or would that prevent the finalizers from running at all? Is there a way to avoid the extra level of indirection (or is GHC sufficiently smart to optimize it away)?

6 9