Okay, I skimmed rts/Schedule.c and now see the problem you mentioned :(
> On the non-threaded runtime the timeslice case doesn't apply and you only
> have one capability, it will force a GC to try to revive some tasks, and if
> at the end of
> this the tasks are still blocked it will release one
I have simply copy pasted the code you provided. Note that my actual code
code doesn't pass anything to a foreign interface. It stores everything in
a Haskell mutable object.
The RTS on completion of actions simply schedules a task which inspects
this objects and wakes up as many blocked tasks as
while making the case of contributing patches with submodule changes more
difficult
I don't understand this, can you give an example of what absolute paths make
harder?
Looking at the wiki pages and scripts we need to make relative paths work for
everyone, I think it's clear that absolute
Moritz Angermann writes:
> Can’t we have absolute submodule paths? Wouldn’t that elevate the
> issue?
>
Perhaps; I mentioned this possibility in my earlier response. It's not
clear which trade-off is better overall, however.
> When we all had branches on ghc/ghc this
> was not an issue.
>
As I
Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the
inliner to respect the pragma?
Thanks and cheers,
Gabor
On 1/8/19, Simon Peyton Jones wrote:
> Oh well, your INLINE pragma is saying "please inline evtRead at every call
> site". And so GHC does exactly that.
>
> That
Oh well, your INLINE pragma is saying "please inline evtRead at every call
site". And so GHC does exactly that.
That seems like obeying the pragma doesn't it?
Simon
| -Original Message-
| From: Gabor Greif
| Sent: 08 January 2019 00:06
| To: Simon Peyton Jones
| Cc: ghc-devs
|
I think you have to follow this:
-- | Data is available to be read.
evtRead :: Event
evtRead = Event 1
{-# INLINE evtRead #-}
On 1/8/19, Simon Peyton Jones wrote:
> Are you sure? GHC.Event isn't used on Windows, so I did this:
>
> =
> module Bar where
>
> newtype Evt = Evt
Are you sure? GHC.Event isn't used on Windows, so I did this:
=
module Bar where
newtype Evt = Evt Int
evtRead :: Evt
evtRead = Evt 33
instance Show Evt where
show = showEvt
showEvt :: Evt -> String
{-# NOINLINE showEvt #-}
showEvt (Evt x) = show x
module Foo
Hi Simon,
a simplifier question...
Roughly a year ago I started learning about imported Ids, their unfoldings etc.
I have very small example program that compiles on Linux.
```haskell
import GHC.Event
main = print evtRead
```
`evtRead` is a newtype-wrapped Int. When you compile above program
Strange, how could the scheduler assume a deadlock if the MVar could be called
from a closure that is still alive? Can you show the code that you're testing?
On Mon, Jan 7, 2019, at 14:09, Phyx wrote:
> Hi Phil,
>
> Thanks for the reply, however that just gives me a forced deadlock removal
Can’t we have absolute submodule paths? Wouldn’t that elevate the issue?
When we all had branches on ghc/ghc this
was not an issue.
Sent from my iPhone
> On 8 Jan 2019, at 5:24 AM, Ben Gamari wrote:
>
> Simon Peyton Jones via ghc-devs writes:
>
>> Would it be worth describing this workflow
Hi John,
I can, but the only reason that would work is because a blocking foreign
call is except from the
deadlock detection code. I can't block on the Handle itself as all the I/O
calls are non-blocking for performance reasons.
Instead what I want to do is just pause the current task, which
Hi Phil,
Thanks for the reply, however that just gives me a forced deadlock removal
as before.
new bound thread (1)
cap 0: schedule()
cap 0: running thread 1 (ThreadRunGHC)
cap 0: thread 1 stopped (blocked on an MVar)
thread1 @ 03205388 is blocked on an MVar @
Ömer Sinan Ağacan writes:
>> However, there is also a slightly more fundamental issue here: GHC's NCG
>> handles DWARF information with block granularity. Fixing this will be a
>> bit more involved. See compiler/nativeGen/Dwarf.hs for details.
>>
>> One alternative would be to just finish debug
Simon Marlow writes:
> Congrats Ben and co! This is a huge step forwards.
>
Thanks!
> submodules are still pulling from git.haskell.org, is there an easy way to
> fix that?
Indeed, Omer's advice is spot on.
Cheers,
- Ben
signature.asc
Description: PGP signature
Simon Peyton Jones via ghc-devs writes:
> Would it be worth describing this workflow explicitly in our "How to
> use GitLab for GHC development" page?
>
Yes, indeed it would. I have asked David, who is currently looking at
revising our contributor documentation, to do so.
Cheers,
- Ben
Would it be worth describing this workflow explicitly in our "How to use GitLab
for GHC development" page?
S
| -Original Message-
| From: ghc-devs On Behalf Of Ben Gamari
| Sent: 07 January 2019 15:33
| To: Moritz Angermann ; ghc-devs
| Subject: Re: GitLab forks and submodules
|
|
Moritz Angermann writes:
> Hi *,
>
> so what do we do with submodules? If you point someone to a fork of ghc, say:
>
> gitlab.haskell.org/foo/ghc
>
Indeed submodules have been a constant thorn in our side. We encounter
this same issue during CI jobs on forks. To work around this we have a
I suspect that you spent a good deal of time in search of this knowledge.
Is there something in this code that could have helped you do this faster?
Unfortunately, the water in flatten_args is indeed deep, and I don't think
there's any way to fix that. I've considered writing a peer-reviewed
I'm on a train, so unable to dig deep.
The standard thing to do is to build the dictionary in the type checker, and
leave it in the syntax tree for the desugarer to use.
The ticket and MR discussion have grown long. Is there an up-do-date
stand-alone description of the currently-proposed
> submodules are still pulling from git.haskell.org, is there an easy way to
> fix that?
`git submodule sync` should fix that.
Ömer
Simon Marlow , 7 Oca 2019 Pzt, 11:42 tarihinde şunu yazdı:
>
> Congrats Ben and co! This is a huge step forwards.
>
> On Thu, 27 Dec 2018 at 06:27, Ben Gamari
Congrats Ben and co! This is a huge step forwards.
On Thu, 27 Dec 2018 at 06:27, Ben Gamari wrote:
>
> git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git
> git remote set-url --push origin g...@gitlab.haskell.org:ghc/ghc
>
> This is all that should be necessary; a quick
Hi Ömer,
I cannot answer you precisely, but when I was working on my type-checker
plugin, I used functions `classTyCon` and `tyConSingleDataCon`,
https://github.com/phadej/kleene-type/blob/cb7332b98ae229e162c12186fd4d7fccb06ab62f/plugin/KleenePlugin/TcPlugin.hs#L331-L336;
i.e. shouldn't be much
23 matches
Mail list logo
