[Haskell] ANNOUNCE: PQC: QuickCheck in the Age of Concurrency
PQC: QuickCheck in the Age of Concurrency An SMP parallel QuickCheck driver Do you: * Have (or want) lots of QuickCheck properties? * Run them often (maybe on every darcs commit)? * Tired of waiting for the testsuite to finish? * Got a multi-core box with cpus sitting idle...? Yes? You need Parallel QuickCheck! PQC provides a single module: Test.QuickCheck.Parallel. This is a QuickCheck driver that runs property lists as jobs in parallel, and will utilise as many cores as you wish, with the SMP parallel GHC 6.6 runtime. It is simple, scalable replacement for Test.QuickCheck.Batch. An example, on a 4 cpu linux server, running 20 quickcheck properties. With 1 thread only: $ time ./a.out 1 1: sort1: OK, 1000 tests. 1: sort2: OK, 1000 tests. 1: sort3: OK, 1000 tests. 1: sort4: OK, 1000 tests. ... ./a.out 1 > x 18.94s user 0.01s system 99% cpu 18.963 total 18 seconds, 99% cpu. But I've got another 3 2.80GHz processors sitting idle! Let's use them, to run the testsuite faster. No recompilation required. 4 OS threads, 4 Haskell threads: $ time ./a.out 4 +RTS -N4 > /dev/null ./a.out 4 +RTS -N4 > /dev/null 20.65s user 0.22s system 283% cpu 7.349 total 283% cpu, not bad. We're getting close to being limited by the length of the longest running test. Or on a dual core macbook, thanks to Spencer Janssen for macbook data and testing: 1 thread: ./Example 1 17.256s 2 threads: ./Example 2 +RTS -N2 10.402s Get it! Homepage: http://www.cse.unsw.edu.au/~dons/pqc.html Haddocks: http://www.cse.unsw.edu.au/~dons/pqc/ Example : http://www.cse.unsw.edu.au/~dons/code/pqc/examples/Example.hs darcs get http://www.cse.unsw.edu.au/~dons/code/pqc Happy, quick checking, Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] SYB Documentation is inconclusive.
On 23-nov-2006, at 23:22, Ralf Lammel wrote: Arthur, constrFields eventually returns some mangled strings from the abstract syntax tree; see ghc-fptools/ghc/compiler/basicTypes/ DataCon.lhs; and that abstract syntax promises to be order-preserving. It says (not surprisingly): dcFields :: [FieldLabel], -- Field labels for this constructor, in the -- same order as the argument types; -- length = 0 (if not a record) or dataConSourceArity. gmapQ maps the children to results. Since it is a map, it is order- preserving. There is not even any associatively business in the case of gmapQ (as opposed to gmapQl and gmapQr). So zipping together results from gmapQ and constrFields plus handling the special case of non-record types, should be just fine, no? What could possibly go wrong? Perhaps you are saying that the documentation of constrFields should promise explicitly that it does not mangle order? Such a promise would have been nice. I assumed that The Right Thing (as in no magic reorderings) would happen, but it was unclear from the papers and the haddock documentation. I should've looked into the source, of course, as that is the definitive documentation. :) Let me know if I don't get what you are after ... perhaps in the café. You have fully understood and explained. Glad to see that The Right Thing is done. Now I can safely go and let my code into the hands of unsuspecting non-Haskellers. :) With regards, Arthur van Leeuwen. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] SYB Documentation is inconclusive.
Arthur, constrFields eventually returns some mangled strings from the abstract syntax tree; see ghc-fptools/ghc/compiler/basicTypes/DataCon.lhs; and that abstract syntax promises to be order-preserving. It says (not surprisingly): dcFields :: [FieldLabel], -- Field labels for this constructor, in the -- same order as the argument types; -- length = 0 (if not a record) or dataConSourceArity. gmapQ maps the children to results. Since it is a map, it is order-preserving. There is not even any associatively business in the case of gmapQ (as opposed to gmapQl and gmapQr). So zipping together results from gmapQ and constrFields plus handling the special case of non-record types, should be just fine, no? What could possibly go wrong? Perhaps you are saying that the documentation of constrFields should promise explicitly that it does not mangle order? Let me know if I don't get what you are after ... perhaps in the café. Ralf > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Arthur van Leeuwen > Sent: Thursday, November 23, 2006 12:09 AM > To: haskell@haskell.org > Subject: [Haskell] SYB Documentation is inconclusive. > > L.S., > > lately I've been playing with Data.Generics and records. I would like > to write a generic method to output to e.g. CSV files. Given > MissingH.CVS > that problem reduces to a generic method to take lists of records to > lists of lists with shown record fields, with as first element a list > of the > field names. That is, something quite like: > > > totable :: [RecordType] -> [[String]] > > totable rs = fields (head rs) ++ map showrecord rs > > where fields a = constrFields . head . dataTypeConstrs . > dataTypeOf $ a > >showrecord = gmapQ (show . toConstr) > > However, there are no guarantees whatsoever that the order of the > fieldnames > returned by constrFields corresponds to the order in which gmapQ returns > the results for the children (that is the fields, in this case) of > the records. > > Furthermore, I see no way of forcing such an order otherwise, other than > writing boilerplate myself. > > So, is there something I just haven't seen in the lib yet, is something > missing, or is just the documentation inconclusive and does the library > behave as I want it to? > > Doei, Arthur. > > -- > >/\/ | [EMAIL PROTECTED] | Work like you don't need > the money > /__\ / | A friend is someone with whom | Love like you have never > been hurt > /\/__ | you can dare to be yourself | Dance like there's nobody > watching > > > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
[sorry for quoting so much, kinda hard to decide here where to snip]
Cale Gibbard wrote:
> On 23/11/06, Jason Dagit <[EMAIL PROTECTED]> wrote:
>> A comment on that video said:
>>
>> - BEGIN QUOTE
>> It seems to me that STM creates new problems with composability.
>> You create two classes of code: atomic methods and non atomic methods.
>>
>> Nonatomic methods can easily call atomic ones ? the compiler could
>> even automatically inject the atomic block if the programmer forgot.
>>
>> Atomic methods and blocks cannot be allowed to call nonatomic code.
>> The nonatomic code could do I/O or other irrevocable things that would
>> be duplicated when the block had to retry.
>> END QUOTE
>>
>> I imagine an example like this (some pseudo code for a side effect
>> happy OO language):
>>
>> class Foo {
>> protected int counter; // assume this gets initialized to 0
>> public doSomething() {
>> atomic{
>> counter++;
>> Console.Write("called doSomething execution# " + counter);
>> // something which could cause the transaction to restart
>> }
>> }
>> public doOtherThing() {
>> atomic{
>> doSomething();
>> // something which could cause the transaction to restart
>> }
>> }
>> }
>>
>> Now imagine doSomething gets restarted, then we see the console output
>> once each time and counter gets incremented. So one solution would be
>> to move the side effects (counter++ and the console write) to happen
>> before the atomic block. This works for doSomething, but now what if
>> we called doOtherThing instead? We're back to having the extra
>> side-effects from the failed attempts at doSomething, right? We just
>> lost composability of doSomething? I'm assuming counter is only meant
>> to be incremented once per successful run of doSomething and we only
>> want to see the output to the log file once per successful run, but it
>> needs to come before the log output inside doSomething so that the log
>> makes sense.
>>
>> I realize STM is not a silver bullet, but it does seem like
>> side-effects do not play nicely with STM. What is the proposed
>> solution to this? Am I just missing something simple? Is the
>> solution to make it so that Console.Write can be rolled back too?
>
> The solution is to simply not allow side effecting computations in
> transactions. They talk a little about it in the video, but perhaps
> that's not clear. The only side effects an atomic STM transaction may
> have are changes to shared memory.
>
> Another example in pseudocode:
>
> atomic
>x <- launchMissiles
>if (x < 5) then retry
>
> This is obviously catastrophic. If launchMissiles has the side effect
> of launching a salvo of missiles, and then the retry occurs, it's
> unlikely that rolling back the transaction is going to be able to put
> them back on the launchpad. Worse yet, if some variable read in
> launchMissiles changes, the transaction would retry, possibly causing
> a second salvo of missiles to be launched.
>
> So you simply disallow this. The content of a transaction may only
> include reads and writes to shared memory, along with pure
> computations. This is especially easy in Haskell, because one simply
> uses a new monad STM, with no way to lift IO actions into that monad,
> but atomically :: (STM a -> IO a) goes in the other direction, turning
> a transaction into IO. In other languages, you'd want to add some
> static typechecking to ensure that this constraint was enforced.
This is of course the technically correct answer. However, I suspect that it
may not be completely satisfying to the practitioner. What if you want or
even need your output to be atomically tied to a pure software transaction?
One answer is in fact "to make it so that Console.Write can be rolled back
too". To achieve this one can factor the actual output to another task and
inside the transaction merely send the message to a transactional channel
(TChan):
atomic $ do
increment counter
counterval <- readvar counter
sendMsg msgChan ("called doSomething execution# " ++ show counterval)
-- something which could cause the transaction to restart
Another task regularly takes messages from the channel and actually outputs
them. Of course the output will be somewhat delayed, but the order of
messages will be preserved between tasks sending to the same channel. And
the message will only be sent if and only if the transaction commits.
Unfortunately I can't see how to generalize this to input as well...
Cheers
Ben
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
On 23/11/06, Jason Dagit <[EMAIL PROTECTED]> wrote:
A comment on that video said:
- BEGIN QUOTE
It seems to me that STM creates new problems with composability.
You create two classes of code: atomic methods and non atomic methods.
Nonatomic methods can easily call atomic ones – the compiler could
even automatically inject the atomic block if the programmer forgot.
Atomic methods and blocks cannot be allowed to call nonatomic code.
The nonatomic code could do I/O or other irrevocable things that would
be duplicated when the block had to retry.
END QUOTE
I imagine an example like this (some pseudo code for a side effect
happy OO language):
class Foo {
protected int counter; // assume this gets initialized to 0
public doSomething() {
atomic{
counter++;
Console.Write("called doSomething execution# " + counter);
// something which could cause the transaction to restart
}
}
public doOtherThing() {
atomic{
doSomething();
// something which could cause the transaction to restart
}
}
}
Now imagine doSomething gets restarted, then we see the console output
once each time and counter gets incremented. So one solution would be
to move the side effects (counter++ and the console write) to happen
before the atomic block. This works for doSomething, but now what if
we called doOtherThing instead? We're back to having the extra
side-effects from the failed attempts at doSomething, right? We just
lost composability of doSomething? I'm assuming counter is only meant
to be incremented once per successful run of doSomething and we only
want to see the output to the log file once per successful run, but it
needs to come before the log output inside doSomething so that the log
makes sense.
I realize STM is not a silver bullet, but it does seem like
side-effects do not play nicely with STM. What is the proposed
solution to this? Am I just missing something simple? Is the
solution to make it so that Console.Write can be rolled back too?
Thanks,
Jason
The solution is to simply not allow side effecting computations in
transactions. They talk a little about it in the video, but perhaps
that's not clear. The only side effects an atomic STM transaction may
have are changes to shared memory.
Another example in pseudocode:
atomic
x <- launchMissiles
if (x < 5) then retry
This is obviously catastrophic. If launchMissiles has the side effect
of launching a salvo of missiles, and then the retry occurs, it's
unlikely that rolling back the transaction is going to be able to put
them back on the launchpad. Worse yet, if some variable read in
launchMissiles changes, the transaction would retry, possibly causing
a second salvo of missiles to be launched.
So you simply disallow this. The content of a transaction may only
include reads and writes to shared memory, along with pure
computations. This is especially easy in Haskell, because one simply
uses a new monad STM, with no way to lift IO actions into that monad,
but atomically :: (STM a -> IO a) goes in the other direction, turning
a transaction into IO. In other languages, you'd want to add some
static typechecking to ensure that this constraint was enforced.
- Cale
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] SimonPJ and Tim Harris explain STM - video
http://channel9.msdn.com/Showpost.aspx?postid=231495 The links to the video are a couple of yellow buttons at the bottom of the article: "Watch" or "Download". I haven't watched this yet (it's nearly an hour long, I think). Found via reddit (http://reddit.com). Haskeller's on TV (sort of...) woot woot! Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] base libraries
This is a small reply to clarify the regular expression situation: Bulat Ziganshin wrote: > Hello libraries, > > after analyzing the situation, i concluded that source of problem, at > least partially, is GHC HQ's policy of packaging libraries with GHC. > The list of such libraries is *closed* and odd at first look. why, for > example, it includes 2 of 4 regexp libs? at last end, we can learn > that this is the list of libs required to build ghc itself! Some of the other regex-* libraries are interfaces to c-library backends (pcre and tre) and it is not GHC's place to come with copies of those libraries. But GHC used regex internally, so it must come with at least a single backend. > [...snip...] > > and while we are here - splitting of Base library should be very easy > task. its ghc version specific part is in GHC.* modules. these modules > should be moved into the new Core library. plus a few modules from > Data.* or System.* hierarchy they imports. plus a few modules imported > by Hugs/NHC Prelude. the rest of Base library should be pretty portable, at > least between various GHC versions. > > and independent on this work, we can always look into moving pieces of > Base into independent libs. as a rule of thumb, everything not used in > Base lib may be moved outside of it. of course, these new libs should > be included in base libs set The regex-* modules that are installed with GHC are not in the "base" package. They are in "regex-base" and "regex-posix" and "regex-compat" because I took excellent design advice and finely split the modules. I see no reason one could not by able to upgrade these on top of the GHC versions. > in particular, my hottest hope is that ghc 6.6.1 will be shipped with > fps 0.8 as separate library that will provide both backward > compatibility with 6.6 and will allow to upgrade fps without recompiling > ghc itself :D By separate library you really mean using a separate package name instead of "base". The Text.XHtml is already separate into the "xhtml" package. You are correct: as far as I can see the only module that is in "base" which might need to be split out is Data.ByteString. The same may or may not apply to Data.Sequence. Cheers, Chris ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] SYB Documentation is inconclusive.
L.S., lately I've been playing with Data.Generics and records. I would like to write a generic method to output to e.g. CSV files. Given MissingH.CVS that problem reduces to a generic method to take lists of records to lists of lists with shown record fields, with as first element a list of the field names. That is, something quite like: > totable :: [RecordType] -> [[String]] > totable rs = fields (head rs) ++ map showrecord rs > where fields a = constrFields . head . dataTypeConstrs . dataTypeOf $ a >showrecord = gmapQ (show . toConstr) However, there are no guarantees whatsoever that the order of the fieldnames returned by constrFields corresponds to the order in which gmapQ returns the results for the children (that is the fields, in this case) of the records. Furthermore, I see no way of forcing such an order otherwise, other than writing boilerplate myself. So, is there something I just haven't seen in the lib yet, is something missing, or is just the documentation inconclusive and does the library behave as I want it to? Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
