Pre-allocation of large memory also causes trouble on Windows
Subsystem for Linux. In that case also, compiling with
--disable-large-address-space solves the problem.
If your OS happens to be Ubuntu, there is an unofficial PPA for GHC
which includes versions of GHC and cabal-install that were comp
Ben, I see #12757 is now fixed and closed. Great!
What's the prognosis now for a release?
Thanks,
Yitz
On Tue, Oct 25, 2016 at 5:01 PM, Ben Gamari wrote:
> George Colpitts writes:
>
>> Hi
>>
>> Where are we on this? 12479 was last updated 5 days ago and it is not clear
>> who has the next acti
The way I understood it, it's because the type of "floating point" literals is
Fractional a => a
so the literal parser has no choice but to go via Rational. Once you
have that, you use the same parser for those Read instances to ensure
that the result is identical to what you would get if you par
Michael Sloan wrote:
> It is really good to think in terms of a cleverness budget...
> Here are the things I see in favor of this proposal:
>
> 1) It is common practice to use -Wall...
> 2) It lets us do things that are otherwise quite inconvenient...
You missed the most important plus:
0) It fix
Yuras Shumovich wrote:
>> Can we generalize the proposal such that subsequent imports shadow
>> preceding ones?
Herbert Valerio Riedel wrote:
> ...iirc there is a different idea...
> allowing explicitly enumerated names...
> to shadow imports from other modules which didn't explicitly name the
> s
Ben, thanks much for the update.
It's not sad that you'll be at ICFP - I wish I could be there too! :)
Historically ICFP has provided much of the juice that GHC runs on.
Enjoy, and good luck with the release.
Regards,
Yitz
On Sun, Sep 18, 2016 at 4:07 PM, Ben Gamari wrote:
>
Are there any updates on 8.0.2? Thanks!
To put things in the perspective of yesod-based commercial GHC users:
Due to #12130, GHC 8 is useless to us until 8.0.2. So for us this is
the most important GHC release in years.
In our particular case, our products are now being held back in very
concrete
Wow, this sounds great!
Just to clarify - this would still be a mingw-w64 build
and not require the msys2 DLLs, correct?
Thanks,
Yitz
On May 21, 2015 23:53, "David Macek" wrote:
> With the helpful pointers from ezyang on IRC, I pushed this a bit forward.
>
> I converted most of the patches into
I wrote:
>> ...I thought that the idea was that we wanted
>> it actually integrated into GHC.
Herbert Valerio Riedel wrote:
> That would be the preferred way from a technical standpoint, as it would
> avoid fork/exec and make it easier to integrate the CPP-phase tighter
> into the lexer/parser.
>
Malcolm Wallace wrote:
> Interesting. I'm not completely clear, when you say
> that your company distributes binaries to third-parties:
> do you distribute ghc itself? Or just the product that
> has been built by ghc?
You're right. We only distribute binaries built by GHC.
So whatever doesn't ma
I wrote:
>> Keeping the license as is seems to be important to Malcolm.
>> So could we have an option to build GHC without cpphs
>> and instead use it as a stand-alone external program?
>> That would make the situation no worse than GMP.
Bardur Arantsson wrote:
> I don't see any need for an option
run.
>
> Respectfully,
>
> Howard
>
>> On May 20, 2015, at 7:39 AM, Yitzchak Gale wrote:
>>
>> The license issue is a real concern for any company using
>> GHC to develop a product whose binaries they distribute to
>> customers. And it is concern for GH
The license issue is a real concern for any company using
GHC to develop a product whose binaries they distribute to
customers. And it is concern for GHC itself, if we want
GHC to continue to be viewed as a candidate for use in
industry.
The real issue is not whether you can explain why this
licen
As I am sure many people have noticed, there is
currently a serious problem with FFI on 64-bit
Windows. It often happens that when you link
in FFI against a standard DLL, the resulting
application segfaults as soon as any function
from the DLL is called.
I experienced this problem with Bryan's tex
Mark Lentczner wrote:
> 1) Abandon the Platform…
>
> 2) Slim the Platform. Pare it back to GHC + base + a smaller set of
> "essential" libs + tools. Keeps a consistent build layout and installation
> mechanism for Haskell.
>
> 3) Re-conceive the Platform. Take a very minimal install approach, coupl
Moving here from Reddit, as suggested by Herbert.
This a continuation of a thread that started with
Edward Yang's post here:
http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-October/025389.html
continued here, a few months later:
http://mail.haskell.org/pipermail/glasgow-haskell-user
-1
There are common idioms that rely on the current behavior,
so I think this would break a lot code.
Examples:
In command line programs, it is very common to use
"error" for printing the usage message.
Many programs use "error" as a general way to exit
from pure code with a message.
I'm not c
Even though my native English is the U.S.
variety, I still haven't gotten used to writing
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
It's a constant compiler error for me. I'm just so accustomed
to the idea that in the Haskell world, U.K. spelling and usage
are the norm.
Would it be difficult t
Here's an update to our efforts to get a working build of text-icu
on Windows 64 bits:
I am working together with Kyra on this on the café list.
It is becoming clear that GHC is unable to use standard
DLLs on Windows 64 bits. That means FFI is really broken
on that platform at the moment.
By "una
I wrote:
> Aha! Thanks [to Bryan] for this explanation of what I have been
> suffering from...
> I can't wait for the point releases. I'll go with HEAD on one
> of the branches for now.
Unfortunately, this patch did *not* fix what I have been suffering from.
I'm still getting segfaults.
I'll desc
Bryan O'Sullivan wrote:
>> It seems that something somewhere in linker-land
>> changed in GHC 7.8 such that packages that include
>> C components now need to be built with
>> position-independent code on some platforms...
>> I am not sure whether the correct fix is to pepper…
>> packages... with "-
Perhaps it would be a good idea to post hashes
on the download site for each downloadable file,
to make it easier to verify that you have the genuine
article.
Thanks,
Yitz
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/list
iedel
wrote:
> On 2014-05-27 at 12:47:53 +0200, Yitzchak Gale wrote:
>> Herbert Valerio Riedel wrote:
>>> What kind of version tweaks are you thinking about? (Afaics, the GHC
>>> bundled libraries don't have any version bumps.)
>>
>> Well for one thing, wo
Herbert Valerio Riedel wrote:
> What kind of version tweaks are you thinking about? (Afaics, the GHC
> bundled libraries don't have any version bumps.)
Well for one thing, wouldn't the version of base be bumped?
If the bugs fixed in 7.8.3 affect any packages in the platform,
we would want to make
Herbert Valerio Riedel wrote:
> Personally, I'd vote for a soon-ish 7.8.3 release for things which
> already have a working good/low-risk fix in ghc-7.8, so the next HP can
> go with 7.8.3 instead of using the known-to-be-suboptimal 7.8.2
It's not certain that the HP team will be able to wait for
Whether or not we provide Duncan's proposed interface,
we need to add prominent warnings about this
to the documentation for every function that has this
issue. People need to be aware that the result of an
async exception will be a gunshot to the head.
On Fri, Nov 15, 2013 at 11:59 PM, Duncan Co
Please forgive me if you received this message twice.
I believe that my first attempt to send it was swallowed
due to my not being a subscriber to the list at that time.
We now have a Windows server with 23 GB of memory
temporarily available this week to work on this GHC crash.
Is there anyone in
27 matches
Mail list logo
