Does this depend on a certain version of gcc?
$ ghc -M --make Matrix.hs -o matrix
Chasing modules from: Matrix.hs
[1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o )
ghc-6.5.20051207: could not execute: gcc-3.4.3
I'm wondering why it is tryi
Shouldn't it work to pass "-M --make"? Or, hmm, maybe -M isn't
generating enough dependencies - like, it seems that it should
generate a dependency for the final output file specified with "-o"
but it isn't...
Frederik
On Wed, Dec 07, 2005 at 11:34:55AM -, Simon Marlow wrote:
> On 04 December
On 08 December 2005 11:52, Claus Reinke wrote:
> is every MVar access is a synchronisation point (in terms of memory
> update propagation between threads, not just in terms of thread
> interaction)?
Yes, it is. On a multiprocessor every MVar operation performs a full
memory barrier internally.
On Dec 8, 2005, at 5:15 AM, Seth Kurtzberg wrote:
[Discussion of the appropriate role of fairness.]
The fundamental requirement is the same for all languages, I believe;
the concurrently executing threads must produce a system state that is
identical to _one_ system state which would be produce
Simon,
Don't worry, your implementation (and any implementation)
has "strong fairness". Just run it enough times that the
hardware fails in the way peoplewant. ;)
Jest aside, I'm totally on your side in this discussion.
Asking an implementation to promise to generate all possible
interleavings
>> If you share IORefs between threads and run on a multiprocessor, you
>> are at the mercy of both sequential optimisations and your
>> architecture's memory consistency guarantees. In other words, don't
>> do it. Use communication primitives that have strong properties in a
>> multi-threaded se
On 08 December 2005 09:40, Simon Marlow wrote:
> If you share IORefs between threads and run on a multiprocessor, you
> are at the mercy of both sequential optimisations and your
> architecture's memory consistency guarantees. In other words, don't
> do it. Use communication primitives that have
On Thu, 2005-12-08 at 09:40 +, Simon Marlow wrote:
> On 07 December 2005 19:57, Claus Reinke wrote:
>
> > there seem to be two issues here - can we agree on that at least?
> >
> > 1) scheduling non-sequential programs on sequential processors
> >
> > i wasn't arguing that the scheduler shoul
On 07 December 2005 19:57, Claus Reinke wrote:
> there seem to be two issues here - can we agree on that at least?
>
> 1) scheduling non-sequential programs on sequential processors
>
> i wasn't arguing that the scheduler should realise all possible
> interleavings at once. the issue i was refer
On Wed, Dec 07, 2005 at 04:45:52PM +, Tony Finch wrote:
> The following paper seems relevant to this thread. Although it's written
> in the context of C and C++, it's relevant to any language that combines
> pre-emptive threads and imperative features.
>
> http://www.hpl.hp.com/techreports/200
10 matches
Mail list logo
