Re: Should we have primitive fill-once variables?

[Carter Schonwald]

i'm a little confused, whats the order of reads here?
Mvars have write wins, whats the order here?  last writer runs first, first
writer runs last? (wouldn't there be starvation issues?)

On Fri, Jun 29, 2018 at 11:51 AM Joachim Breitner 
wrote:

> Hi,
>
> when reading the subject I was expecting something like this:
>
>-- | Creates an empty IVar
>newIVar :: IO (IVar a)
>
>-- | pure! but blocks until the IVar is written
>readIVar :: IVar a -> a
>
>-- | tries to write to an IVar.
>-- Succeeds if it is empty (returning True)
>-- Does nothing if it has been written to (returning False)
>writeIVar :: IVar a -> a -> IO Bool
>
> Alternatively:
>
>-- | all in one
>newIVar :: IO (a, a -> IO Bool)
>
>
> Essentially a thunk, but with explicit control over filling it.
> In fact, people have implemented something like this using C-- hacks
> before: https://github.com/twanvl/unsafe-sequence
>
> > This would make MonadFix's implementation much nicer, I think :)
>
> This would suffice for MonadFix, right?
>
> Sorry for derailing the thread :-)
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   m...@joachim-breitner.de
>   http://www.joachim-breitner.de/
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we have primitive fill-once variables?

[Carter Schonwald]

*first write first

On Fri, Jun 29, 2018 at 12:19 PM Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> i'm a little confused, whats the order of reads here?
> Mvars have write wins, whats the order here?  last writer runs first,
> first writer runs last? (wouldn't there be starvation issues?)
>
> On Fri, Jun 29, 2018 at 11:51 AM Joachim Breitner <
> m...@joachim-breitner.de> wrote:
>
>> Hi,
>>
>> when reading the subject I was expecting something like this:
>>
>>-- | Creates an empty IVar
>>newIVar :: IO (IVar a)
>>
>>-- | pure! but blocks until the IVar is written
>>readIVar :: IVar a -> a
>>
>>-- | tries to write to an IVar.
>>-- Succeeds if it is empty (returning True)
>>-- Does nothing if it has been written to (returning False)
>>writeIVar :: IVar a -> a -> IO Bool
>>
>> Alternatively:
>>
>>-- | all in one
>>newIVar :: IO (a, a -> IO Bool)
>>
>>
>> Essentially a thunk, but with explicit control over filling it.
>> In fact, people have implemented something like this using C-- hacks
>> before: https://github.com/twanvl/unsafe-sequence
>>
>> > This would make MonadFix's implementation much nicer, I think :)
>>
>> This would suffice for MonadFix, right?
>>
>> Sorry for derailing the thread :-)
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   m...@joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Plan for GHC 8.6.1

[Carter Schonwald]

current cabal has a nasty build failure on haddock errors, i'd really
appeciate some eyeballs / attention / ideas on how to get my fix / PR for
it over the finish line for GHC 8.6
https://github.com/haskell/cabal/pull/5269

(the issue is that haddock failures, such as on an empty package, fail an
entire build)

On Sun, Jun 24, 2018 at 12:56 PM Ben Gamari  wrote:

> George Colpitts  writes:
>
> > I agree.
> >
> > So back to my original question: will ghc 8.6.1 be moving to llvm 6 from
> > llvm 5?
> >
> Ahh, whoops, missed the original question!
>
> 8.6 will use LLVM 6.0.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we have primitive fill-once variables?

[David Feuer]

On Friday, June 29, 2018 11:51:07 AM EDT Joachim Breitner wrote:
> when reading the subject I was expecting something like this:
>
>-- | pure! but blocks until the IVar is written
>readIVar :: IVar a -> a 
>
>-- | tries to write to an IVar. 
>-- Succeeds if it is empty (returning True)
>-- Does nothing if it has been written to (returning False)
>writeIVar :: IVar a -> a -> IO Bool

It really depends. Are there useful (compile-time or run-time) optimization for 
IVars (write-once) that don't apply to QVars (fill-once)? If so, we might 
indeed want to offer writeIVar as you suggest, and

> readIVar :: IVar a -> (# a #)

The unboxed tuple allows the value to be extracted from the IVar without being 
forced. If, however, we want QVars, we can always simulate that using 
accursedUnutterablePerformIO:

> readIVarPure (IVar var) = case readIVar# var realWorld# of (# _, a #) -> (# a 
> #)

I don't know if there are useful IVar optimizations or not. If so, we should 
take them; if not, we should take the extra flexibility.

> Alternatively:
> 
>-- | all in one
>newIVar :: IO (a, a -> IO Bool)

Does this have some advantage as a primop?

> In fact, people have implemented something like this using C-- hacks
> before: https://github.com/twanvl/unsafe-sequence

I'll have to take a look.

> > This would make MonadFix's implementation much nicer, I think :)
> 
> This would suffice for MonadFix, right?

It should indeed.

Side note: my implementation sketch for readQVar was missing one piece: after a 
reader pushes itself on the stack, it must check the QVar status a second time 
in case the QVar was filled between the read and the enstackment. If it's been 
filled, it needs to awaken the first thread the way writeQVar would. Indeed, it 
might as well check the QVar status on every trip through the CAS loop.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we have primitive fill-once variables?

[David Feuer]

On Friday, June 29, 2018 12:19:53 PM EDT Carter Schonwald wrote:
> i'm a little confused, whats the order of reads here?
> Mvars have write wins, whats the order here?  last writer runs first, first
> writer runs last? (wouldn't there be starvation issues?)

Writes would occur in no particular order (very much like atomicWriteIORef). 
Blocked reads would occur from last to first, and I think that's okay. If you 
think about this as being primarily intended to implement IVars, but with a 
little extra flexibility, you should get the right intuition.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we have primitive fill-once variables?

[David Feuer]

On Friday, June 29, 2018 2:13:39 PM EDT Joachim Breitner wrote:

> I don’t know! Maybe the GC can treat a filled IVar differently (because
> it is no longer mutable?) But really, I don't know :-)

That's a very good point. If we turn the IVar into a pure value, then it loses 
its "dirty" bit and the GC no longer has to check whether it's pointing to a 
newer generation. But this is getting into territory that's pretty murky to me.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we have primitive fill-once variables?

[David Feuer]

On Friday, June 29, 2018 12:54:23 PM EDT David Feuer wrote:

> The unboxed tuple allows the value to be extracted from the IVar without 
> being forced. If, however, we want QVars, we can always simulate that using 
> accursedUnutterablePerformIO:

Actually, this might be silly, depending on implementation details. Twan's 
technique (which may or may not be directly relevant) overwrites a closure with 
its final value, which is a pretty good match for your approach. We still need 
to be able to implement tryRead[IQ]Var; I'm not sure what limitations that 
imposes.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we have primitive fill-once variables?

[Joachim Breitner]

Hi,

Am Freitag, den 29.06.2018, 12:54 -0400 schrieb David Feuer:
> On Friday, June 29, 2018 11:51:07 AM EDT Joachim Breitner wrote:
> > when reading the subject I was expecting something like this:
> > 
> >-- | pure! but blocks until the IVar is written
> >readIVar :: IVar a -> a 
> > 
> >-- | tries to write to an IVar. 
> >-- Succeeds if it is empty (returning True)
> >-- Does nothing if it has been written to (returning False)
> >writeIVar :: IVar a -> a -> IO Bool
> 
> It really depends. Are there useful (compile-time or run-time)
> optimization for IVars (write-once) that don't apply to QVars (fill-
> once)? If so, we might indeed want to offer writeIVar as you suggest,
> and

I don’t know! Maybe the GC can treat a filled IVar differently (because
it is no longer mutable?) But really, I don't know :-)

Cheers,
Joachim
-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: GHC.Prim.Int# is not at TyThing?

[Simon Peyton Jones via ghc-devs]

Are you sure that Int# is in (lexical scope) in the GlobalRdrEnv of the HscEnv? 
If not, looking up the String in the lexicial environment will fail.

You can always just grab TysPrim.intPrimTyCon.

Simon

From: Ranjit Jhala 
Sent: 29 June 2018 00:55
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: Re: GHC.Prim.Int# is not at TyThing?

Dear Simon (and all),

Thanks! Then it seems my problem is much worse: somehow the code
I had that used the `HscEnv` to "resolve" names (i.e. get `Name`
and then `TyThing` and then `TyCon`) from plain strings is no
longer working with the GHC 8.4.3.

My efforts to distill the relevant LH code into a simple test that
shows the difference between the two versions (GHC 8.2 and 8.4) have
proven fruitless so far.

Can anyone point me to a (small?) example of using the GHC API
that implements something like:

   lookupVarType :: String -> IO String

which

   takes a `String` corresponding to the name of a top-level binder as input,
   and returns a `String` containing the TYPE of the binder as output?

Thanks!

- Ranjit.








On Thu, Jun 28, 2018 at 3:48 AM Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Does the above indicate that in fact, 
`GHC.Prim.Int#`
 DOES NOT (any longer) correspond to a `TyCon`?
No, it does not indicate that!  There still is a TyCon for Int#.  Indeed you 
can see it defined in TysPrim.intPrimTyCon.

Simon


From: Ranjit Jhala mailto:jh...@cs.ucsd.edu>>
Sent: 28 June 2018 06:08
To: ghc-devs@haskell.org; Simon Peyton Jones 
mailto:simo...@microsoft.com>>
Subject: 
GHC.Prim.Int#
 is not at TyThing?

Hi all,

I am trying to update LiquidHaskell to GHC 8.4.

In doing so, I find that I can no longer resolve
(i.e. get the `TyThing`, and hence `TyCon`)
corresponding to the name:

   
GHC.Prim.Int#

It seems like in older versions, we had

   λ> :i 
GHC.Prim.Int#
   data 
GHC.Prim.Int#
 -- Defined in ‘GHC.Prim’
   λ> :k 
GHC.Prim.Int#
   
GHC.Prim.Int#
 :: #

but in GHC 8.4 this is changed so:

   λ> :i 
GHC.Prim.Int#
   data 
GHC.Prim.Int#
 :: TYPE 'GHC.Types.IntRep
  -- Defined in ‘GHC.Prim’
   λ> :k 
GHC.Prim.Int#
   

Harbormaster: Build failure on OS/X build. How to fix it as a non Mac user

[Roland Senn]

Hi all,

Phabricator informed me, that the builds on Harbourmaster for my
changes failed. 

Looking at the log at https://phabricator.haskell.org/B21368 I can see,
that the builds on Linux and Windows succeeded, however the tests on
OS/X failed.

Looking at the failed tests at https://phabricator.haskell.org/harborma
ster/build/48354/ it tells me that the 2 tests TEST="T5631 T6048"
failed.

Now, I don't own a machine with OS/X. How can I look, what really
failed, and how can I try to fix it?

Many thanks
   Roland 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Harbormaster: Build failure on OS/X build. How to fix it as a non Mac user

[Ben Gamari]

Roland Senn  writes:

> Hi all,
>
Hi Roland,

it looks like the failing tests are performance tests. These
unfortunately do spuriously fail occasionally. Given the nature of your
patch it seems extremely unlikely that the failure is your fault. Feel
free to ignore it and I will sort it out when I go to merge.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we have primitive fill-once variables?

[Joachim Breitner]

Hi,

when reading the subject I was expecting something like this:

   -- | Creates an empty IVar
   newIVar :: IO (IVar a)

   -- | pure! but blocks until the IVar is written
   readIVar :: IVar a -> a 

   -- | tries to write to an IVar. 
   -- Succeeds if it is empty (returning True)
   -- Does nothing if it has been written to (returning False)
   writeIVar :: IVar a -> a -> IO Bool 

Alternatively:

   -- | all in one
   newIVar :: IO (a, a -> IO Bool)


Essentially a thunk, but with explicit control over filling it.
In fact, people have implemented something like this using C-- hacks
before: https://github.com/twanvl/unsafe-sequence

> This would make MonadFix's implementation much nicer, I think :)

This would suffice for MonadFix, right?

Sorry for derailing the thread :-)

Cheers,
Joachim

-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Harbormaster: Build failure on OS/X build. How to fix it as a non Mac user

[Phyx]

Hi,

They are stats failures. Not good enough, which means you have a regression
in memory usage. Look at the full test log
https://phabricator.haskell.org/harbormaster/build/48354/1/?l=100

They also failed on windows, but currently harbormaster doesn't fail when
tests fail for windows. Clicking the build log will show you they failed on
windows too.

Regards,
Tamar

On Fri, Jun 29, 2018, 16:35 Roland Senn  wrote:

> Hi all,
>
> Phabricator informed me, that the builds on Harbourmaster for my
> changes failed.
>
> Looking at the log at https://phabricator.haskell.org/B21368 I can see,
> that the builds on Linux and Windows succeeded, however the tests on
> OS/X failed.
>
> Looking at the failed tests at https://phabricator.haskell.org/harborma
> ster/build/48354/
>  it tells me
> that the 2 tests TEST="T5631 T6048"
> failed.
>
> Now, I don't own a machine with OS/X. How can I look, what really
> failed, and how can I try to fix it?
>
> Many thanks
>Roland
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: GHC.Prim.Int# is not at TyThing?

[Simon Peyton Jones via ghc-devs]

Well what is lexically in scope is, well, whatever should be lexically in scope 
at that point.  Yes, I suppose your lexicial environment might have changed, 
but I can’t speculate as to why.

Starting with Strings makes you vulnerable to this.

Starting with an “Orig” RdrName would be more robust.

Simon

From: Ranjit Jhala 
Sent: 29 June 2018 15:26
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: Re: GHC.Prim.Int# is not at TyThing?

Dear Simon,

Yes I expect that the notion of what is in scope in the GlobalRdrEnv has 
changed across the GHC versions?

Earlier, these lookups would succeed but now (likely due to some artifact of 
how we are using the API) they fail.

You are right that we can get Int# from the wiredInTyCons; but the issue arises 
with other names (eg “Fractional”)

Which are not (?) wiredIn.


The silver lining is this may force us to redo the LH name resolution entirely 
in a “lazy” fashion only using those Var and Type

That actually appear in the core being analyzed (as opposed to the current 
“eager” fashion where we use the hscenv to

lookup all names in the LH prelude...)

Thanks!

Ranjit.

On Fri, Jun 29, 2018 at 12:21 AM Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Are you sure that Int# is in (lexical scope) in the GlobalRdrEnv of the HscEnv? 
If not, looking up the String in the lexicial environment will fail.

You can always just grab TysPrim.intPrimTyCon.

Simon

From: Ranjit Jhala mailto:jh...@cs.ucsd.edu>>
Sent: 29 June 2018 00:55
To: Simon Peyton Jones mailto:simo...@microsoft.com>>
Cc: ghc-devs@haskell.org
Subject: Re: 
GHC.Prim.Int#
 is not at TyThing?

Dear Simon (and all),

Thanks! Then it seems my problem is much worse: somehow the code
I had that used the `HscEnv` to "resolve" names (i.e. get `Name`
and then `TyThing` and then `TyCon`) from plain strings is no
longer working with the GHC 8.4.3.

My efforts to distill the relevant LH code into a simple test that
shows the difference between the two versions (GHC 8.2 and 8.4) have
proven fruitless so far.

Can anyone point me to a (small?) example of using the GHC API
that implements something like:

   lookupVarType :: String -> IO String

which

   takes a `String` corresponding to the name of a top-level binder as input,
   and returns a `String` containing the TYPE of the binder as output?

Thanks!

- Ranjit.








On Thu, Jun 28, 2018 at 3:48 AM Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Does the above indicate that in fact, 
`GHC.Prim.Int#`
 DOES NOT (any longer) correspond to a `TyCon`?
No, it does not indicate that!  There still is a TyCon for Int#.  Indeed you 
can see it defined in TysPrim.intPrimTyCon.

Simon


From: Ranjit Jhala mailto:jh...@cs.ucsd.edu>>
Sent: 28 June 2018 06:08
To: ghc-devs@haskell.org; Simon Peyton Jones 
mailto:simo...@microsoft.com>>
Subject: 
GHC.Prim.Int#
 is not at TyThing?

Hi all,

I am trying to update LiquidHaskell to GHC 8.4.

In doing so, I find that I can no longer resolve
(i.e. get the `TyThing`, and hence `TyCon`)
corresponding to the name:

   
GHC.Prim.Int#

It seems like in older versions, we had

   λ> :i 
GHC.Prim.Int#
   data 
GHC.Prim.Int#
 -- Defined in ‘GHC.Prim’
   λ> :k 

Re: Should we have primitive fill-once variables?

[Ryan Trinkle]

This would make MonadFix's implementation much nicer, I think :)

On Fri, Jun 29, 2018 at 9:14 AM, Oleg Grenrus  wrote:

> I have wanted something like that! Also similiar STM TQVar would be nice
> to have. For example `async` uses TMVar where the value is written only
> once. if once filled the QVar cannot be empty is useful property.
>
> For STM variant, I'd actually like to have
>
> putTQVar' :: QTVar a -> a -> STM (TVar a)
>
> i.e. giving me back a `TVar a`, for which I now the value is already
> there (i.e. reading won't block). Not sure what the would be such for
> IO, IORef doesn't feel right.
>
> - Oleg
>
> On 29.06.2018 08:28, David Feuer wrote:
> > IVars (write-once variables) can be useful for various purposes. In
> Haskell, they can be implemented using MVars. But MVars are not the
> lightest things in the world. I'm wondering if it might pay to implement
> something much lighter primitively. Here's a sketch of some things I'll
> tentatively call QVars.
> >
> > A QVar has two fields: a value (possibly null) and a stack (no need for
> a queue) of waiting threads.
> >
> > newEmptyQVar: Create a QVar with a null value and an empty queue.
> >
> > tryReadQVar: Just look at the value.
> >
> > readQVar: Check if the value is null (simple memory read). If not, use
> it. If so, push yourself onto the waiting stack (CAS loop). The code that
> will run when you're awakened will try to awaken the next thread if there
> is one (CAS loop).
> >
> > putQVar: Install a new value and get the old one (exchange). If the old
> value was null, mark the QVar dirty. Awaken the first thread if there is
> one (CAS loop). Return the old value if it was non-null (this can be used
> in library code to make duplicate writes, or non-equal duplicate writes, an
> error).
> >
> > I think we'd probably also want atomic modification operations, but I
> haven't figured out which ones yet.
> >
> > Implementation differences from MVars:
> >
> > * We have two fields instead of three (because we can get away with a
> stack instead of a queue).
> >
> > * We never need to lock the QVar closure. MVars do: they can change
> freely between empty and full, so it's necessary to coordinate between
> value and queue modifications.
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we have primitive fill-once variables?

[Oleg Grenrus]

I have wanted something like that! Also similiar STM TQVar would be nice
to have. For example `async` uses TMVar where the value is written only
once. if once filled the QVar cannot be empty is useful property.

For STM variant, I'd actually like to have

putTQVar' :: QTVar a -> a -> STM (TVar a)

i.e. giving me back a `TVar a`, for which I now the value is already
there (i.e. reading won't block). Not sure what the would be such for
IO, IORef doesn't feel right.

- Oleg

On 29.06.2018 08:28, David Feuer wrote:
> IVars (write-once variables) can be useful for various purposes. In Haskell, 
> they can be implemented using MVars. But MVars are not the lightest things in 
> the world. I'm wondering if it might pay to implement something much lighter 
> primitively. Here's a sketch of some things I'll tentatively call QVars.
>
> A QVar has two fields: a value (possibly null) and a stack (no need for a 
> queue) of waiting threads.
>
> newEmptyQVar: Create a QVar with a null value and an empty queue.
>
> tryReadQVar: Just look at the value.
>
> readQVar: Check if the value is null (simple memory read). If not, use it. If 
> so, push yourself onto the waiting stack (CAS loop). The code that will run 
> when you're awakened will try to awaken the next thread if there is one (CAS 
> loop).
>
> putQVar: Install a new value and get the old one (exchange). If the old value 
> was null, mark the QVar dirty. Awaken the first thread if there is one (CAS 
> loop). Return the old value if it was non-null (this can be used in library 
> code to make duplicate writes, or non-equal duplicate writes, an error).
>
> I think we'd probably also want atomic modification operations, but I haven't 
> figured out which ones yet.
>
> Implementation differences from MVars:
>
> * We have two fields instead of three (because we can get away with a stack 
> instead of a queue).
>
> * We never need to lock the QVar closure. MVars do: they can change freely 
> between empty and full, so it's necessary to coordinate between value and 
> queue modifications.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs