22-11-2017, Срд а 15:37 -0500, David Feuer напісаў:
> If there is indeed a problem, I suspect the right way to fix it is to
> make sure that no partially evaluated thunk is ever resumed twice.
> Inter-thread exceptions are presumably rare enough that we don't have
> to worry *too* much about their
Yuras Shumovich writes:
> Hello,
>
Hello,
Sorry for the late reply; this required a bit of reflection. The
invariants surrounding the suspension of ST computations is a rather
delicate and poorly documented area.
I believe the asynchronous exception case which you point out is
precisely #13615.
So my theory is correct, but it is already fixed in 8.2. Nice!
Thank you for clarification!
Yuras.
23-11-2017, Чцв а 10:20 -0500, Ben Gamari напісаў:
> Yuras Shumovich writes:
>
> > Hello,
> >
>
> Hello,
>
> Sorry for the late reply; this required a bit of reflection. The
> invariants surr
Looks like GHC 7.8 is pretty near release.
And while I know that we really like to have a GHC out for a while, and
perhaps see the .1 release, before we incorporate it into the Platform,
this GHC, while including many new and anticipated things, seems pretty
well hammered on.
Combine that with th
+1
On Jan 19, 2014 3:15 PM, "Mark Lentczner" wrote:
> Looks like GHC 7.8 is pretty near release.
>
> And while I know that we really like to have a GHC out for a while, and
> perhaps see the .1 release, before we incorporate it into the Platform,
> this GHC, while including many new and anticipat
+1
I'm just a user, but I'm very excited about the possibility of getting a
GHC 7.8 platform release sooner than later (especially considering Mio and
the other great additions). Another release with the same GHC wouldn't do
me much good.
On Sun, Jan 19, 2014 at 3:14 PM, Mark Lentczner wrote:
>
On Mon, Jan 20, 2014 at 9:29 AM, Andres Löh wrote:
> I can understand the motivation of this proposal, but I'm slightly worried:
+1
> (2) Simply because GHC 7.8 is itself so long delayed and so full of
> new features, I think it's realistic to assume that quite a few
> library glitches will appe
On 20 January 2014 17:29, Andres Löh wrote:
> (2) Simply because GHC 7.8 is itself so long delayed and so full of
> new features, I think it's realistic to assume that quite a few
> library glitches will appear even after it's released. Also, GHC bugs
> may be found only after formal release (des
Just a quick +1 for including GHC 7.8 in the next HP release.
Regarding compiler features, shipping GHC 7.6.3 again would mean that
the HP is still roughly at September 2012 (the first release of GHC
7.6.x). Furthermore, I don't fully buy into the argument that we
should wait for 7.8 to stabilize:
Indeed. Perhaps more importantly: many long standing problems, relating to
how ghci linking works on every major platform, and having win64 support,
look to be resolved In 7.8. These are HUGE. Additionally the Cpp that's a
bother on osx and bsd systems matter goes away for HP if the next release
>
> I know it is difficult but if ghc and haskell-platform could align
> their schedules better then things might be easier to plan in the future.
>
Really I would like to see a HP release now *and* one after 7.8.1! :)
I think HP beta releases should follow each ghc release
and there can be additi
Jens,
are you willing to undertake providing support for all the problems in
current 7.6 on ALL platforms right now?
Are you willing to test the builds on all platforms, and be the person to
help everyone who's hitting issues?
doing an HP release now will push back the release timeline of an HP
v
A few specific points:
1) 2013.4.0.0 isn't really "ready to be pushed" - there were delays, and
then some rolling updates... and some churn. While there is a proposed set
of packages... and it does compile... there is still some work on the Mac
version (it needs to incorporate my patch script for
On 2014-02-27 at 01:14:38 +0100, Austin Seipp wrote:
> Hello all,
>
> The RC2 source distribution is here:
>
> http://www.haskell.org/ghc/dist/7.8.1-rc2/
>
> Please build from it directly. It matches the HEAD of the ghc-7.8
> branch as of now - e9212f0edbd3fddc3836ccded10d036c01d38505
>
> Like la
Speaking from the vantage point of platform This pair of comments
(emphasis mine) have my alarm index on high:
On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell wrote:
> I'm quite worried about this change though. I thought the default rolefor
> data type was nominal, as that's the safe default.
2014-03-24 15:14 GMT+01:00 Mark Lentczner :
> Speaking from the vantage point of platform This pair of comments
> (emphasis mine) have my alarm index on high:
>
> On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell
> wrote: [...]
>> So, the best thing we came up with is this: Libraries that wish to
On Mon, Mar 24, 2014 at 7:28 AM, Brandon Allbery wrote:
> No; if the default is representational, everything works as it did in
> earlier versions, potential bugs/unsafety and all. If the default is
> immediately switched to nominal, *then* every affected type must be
> reviewed immediately.
>
No
Apols if I'm overstating the case, but let me try to clear things up.
Roles are not in place to provide a "safe" cheap coerce. Roles are in
place to _prevent_ an unsoundness with newtype deriving in the presence
of type families. They also happen to _allow_ a cheaper coerce. The
unsoundness is
On 2014-04-15 at 06:52:42 +0200, Jan Stolarek wrote:
>> I think Simon Marlow is even more conservative, and
>> does his validate builds in a separate tree so he catches missing
>> files.
> I thought everyone is doing that.
Btw, using such a workflow[1] is actually almost a necessity if you want
Unsubscribe
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
I don't understand. By they do you mean the HsOpenSSL team? As I've
written twice in this thread I have installed openssl via brew so I don't
know why you are telling me to install it via brew . I've referenced the
HsOpenSSL github page that has an issue on the use of openssl saying it is
broken i
TL;DR. If you see your name in one of the two lists below, please edit
the entries for your contributions to 8.0 and plans for 8.2 in
the 2016 GHC HCAR report [1]. The deadline is in a few short
weeks so act soon!
Hello GHC people,
As you might know, it's that time of the ye
Ben Gamari writes:
> [ Unknown signature status ]
> TL;DR. If you see your name in one of the two lists below, please edit
>the entries for your contributions to 8.0 and plans for 8.2 in
>the 2016 GHC HCAR report [1]. The deadline is in a few short
>weeks so act soon!
>
Th
Hello everyone,
I was doing some maintenance on the mailman server that hosts this list, and
several messages that were stuck in the queue for what appears to be a rather
long time have been released. The queue is now empty, so if these messages are
no longer relevant, please ignore them.
--
Joh
Yes, but it is not feasible before GHC 8.6, due to needing GHC >= 8.2 for
bootstrapping.
True. But 8.4 will fork off shortly; so once that is done, we are happy with
perf, we can add the change to master in preparation for 8.6.
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Beha
If the conclusion is that there's a bug here, could someone distil the example
into a ticket?
Thanks
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben
| Gamari
| Sent: 23 November 2017 15:20
| To: Yuras Shumovich ; ghc-devs
| Subject: Re
26 matches
Mail list logo