If you don't mind threads moving around between calls to your
primitives, this should be ok.
Cheers,
Simon
On 27/10/2015 23:35, Edward Kmett wrote:
Would anything go wrong with a thread id if I pinned it to a capability
after the fact?
I could in theory do so just by setting
tso->flags |= TS
> I would recommend against moving code reviews to Github.
> I like it and use it all the time for my own projects, but for a large
> project like GHC, its code reviews are too basic (comments get lost in
> multi-round reviews), and its customisation an process enforcement is
> too weak; but that h
I figured as much :D
On Wed, Oct 28, 2015 at 4:43 PM, Edward Kmett wrote:
> If the number of capabilities is increased or decreased while everything I
> have here is running I'm going to have to blow up the world anyways.
>
> Basically I'll need to rely on an invariant that setNumCapabilities is
If the number of capabilities is increased or decreased while everything I
have here is running I'm going to have to blow up the world anyways.
Basically I'll need to rely on an invariant that setNumCapabilities is
called before you spin up these Par-like computations.
-Edward
On Wed, Oct 28, 20
A thread with TSO_LOCKED can be migrated if the number of capabilities
decreases.
Ryan
On Tue, Oct 27, 2015 at 11:35 PM, Edward Kmett wrote:
> Would anything go wrong with a thread id if I pinned it to a capability
> after the fact?
>
> I could in theory do so just by setting
>
> tso->flags |=
I have also written my thoughts on the questions posed by Richard on the
wiki page.
On Wed, Oct 28, 2015 at 7:07 AM, Richard Eisenberg
wrote:
>
> On Oct 28, 2015, at 10:02 AM, "Augustsson, Lennart" <
> lennart.augusts...@sc.com> wrote:
>
> > I've put in my answers to your questions.
>
> And I
On Wed, Oct 28, 2015 at 9:19 AM, Richard Eisenberg
wrote:
> I don't have terribly much to add, but I do want to counter one point:
>
> On Oct 28, 2015, at 5:48 AM, Edward Kmett wrote:
> > There are situations where we are truly polymorphic in lifting, e.g.
> (==) from Eq and compare from Ord do
On Wed, Oct 28, 2015 at 5:05 AM, Simon Peyton Jones
wrote:
> I'm out of bandwidth at the moment, but let me just remark that this is
> swampy territory. It's easy to mess up.
>
> A particular challenge is polymorphism:
>
> map :: forall a b. (a->b) -> [a] -> [b]
> map f (x:xs) = (f x) : (map
I think this is a good idea
Alan
On Wed, Oct 28, 2015 at 12:17 AM, Simon Peyton Jones
wrote:
> Ahh. I think I get it. The trouble is that ConDecl doesn’t have the same
> structure as what the user wrote.
>
>
>
> Maybe we should just fix that? How about this declaration? Would that
> make the
On Oct 28, 2015, at 10:02 AM, "Augustsson, Lennart"
wrote:
> I've put in my answers to your questions.
And I've responded.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
On Oct 28, 2015, at 7:39 AM, Ben Gamari wrote:
> It does look pretty reasonable but keep in mind that there are a number
> of comments on the Phabricator Diff that still need to be addressed.
And I have three burning questions at the bottom of the wiki page
https://ghc.haskell.org/trac/ghc/wik
I don't have terribly much to add, but I do want to counter one point:
On Oct 28, 2015, at 5:48 AM, Edward Kmett wrote:
> There are situations where we are truly polymorphic in lifting, e.g. (==)
> from Eq and compare from Ord don't care if the arguments of type 'a' are
> lifted or not.
But
Iavor Diatchki writes:
>> I think that the branch should be in an OK state, except that it is not
>> merged with the latest HEAD.
>
It does look pretty reasonable but keep in mind that there are a number
of comments on the Phabricator Diff that still need to be addressed.
Thanks!
- Ben
signa
On Wed, Oct 28, 2015 at 5:05 AM, Simon Peyton Jones
wrote:
> I'm out of bandwidth at the moment, but let me just remark that this is
> swampy territory. It's easy to mess up.
>
> A particular challenge is polymorphism:
>
> map :: forall a b. (a->b) -> [a] -> [b]
> map f (x:xs) = (f x) : (map
I'm out of bandwidth at the moment, but let me just remark that this is swampy
territory. It's easy to mess up.
A particular challenge is polymorphism:
map :: forall a b. (a->b) -> [a] -> [b]
map f (x:xs) = (f x) : (map f xs)
In the compiled code for map, is a thunk built for (f x), or is i
15 matches
Mail list logo
