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
*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
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
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
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
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
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
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
> >
>
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:
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
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
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
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
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
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
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)
16 matches
Mail list logo
