The installation (and using the 32bit GHC on a 64bit Linux, to an extent)
should now be possible, as described at
https://ghc.haskell.org/trac/ghc/wiki/Building/Compiling32on64
On Fri, Apr 11, 2014 at 08:58:51AM -0500, Austin Seipp wrote:
> Kyrill,
>
> I think that at the moment, you can't reall
> status.haskell.org
Yay, that's neat.
> I'll keep everyone posted
Thank you, Austin.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Well, sorf-of. A few extra unobvious parameters and workarounds
are required in each case, but it's doable, (arguably) simpler
than real cross-compilation and already exhibits problems
that real cross-compilation may in some circumstances face.
Wiki pages (kudos to all previous authors):
http://w
(cross-com^H^H^Hposting to glasgow-haskell-us...@haskell.org)
Well, sorf-of. A few extra unobvious parameters and workarounds
are required in each case, but it's doable, (arguably) simpler
than real cross-compilation and already exhibits problems
that real cross-compilation may in some circumstanc
> Our intent has always been that that the latest version on each branch is
> solid. There have been one or two occasions when we have knowingly abandoned
> a dodgy release branch entirely, but not many.
Perhaps we could do the opposite. Announce beforehand that
a release branch X is going to b
Hi Bulat!
Is this exactly the same email you posted to
glasgow-haskell-users@ previously (I'm asking to know
if I need to reread)? It was already forwarded here by none
other but SPJ. :)
Welcome,
Mikolaj
On Wed, Oct 15, 2014 at 12:01 AM, Bulat Ziganshin
wrote:
> Hello,
>
> i'm looking a the
>
> Now I want to rebase to clean up. Can I just do a local rebase and then git
> push? Nothing special about the push?
You need 'push -f' to force overwriting the old version
of your branch. Please make sure you are not forcefully
pushing while on master branch, though. ;)
(I seem to remember 'pu
> Right! I'm on branch wip/new-flatten-skolems-Oct14, so
> git push --force
> should push just that branch right?
Right. But don't trust me, try with --dry-run.
> If I want to be super-safe, and say "push only this branch" would I say
>
> git push --force HEAD
> or
> git
> The current situation is suboptimal, as it's unclear where the threshold
> for adding yourself as an author to a module header is
> (whitespace/indentation cleanups, fixing/writing docs, removing lines,
> adding a 5-line function in a 500 line module, ...?), and it's a bit
> unfair to those that
On Fri, Oct 31, 2014 at 12:37 PM, Daniel Trstenjak
wrote:
> To ensure, that you're only operating on your current branch you can
> add to your '~/.gitconfig':
>
> [push]
>default = simple
Oh, useful.
> > (I seem to remember 'push -f' can be blocked on master,
> > but I don't know if it is in
Yes, unfortunatley, hackage was down. See
https://status.haskell.org/
I think it's being brought up right now by our fearless
volunteer infrastructure rapid response team (they are drafting!).
Please try again.
On Fri, Oct 31, 2014 at 8:45 PM, George Colpitts
wrote:
> When I type
>
> cabal upda
> Starting with GHC 7.8.x, fingerprints are written into
> annotated & gpg-signed release tags:
>
> http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release
>
> That way you're able to restore via the fingerprint for a given release
> via:
>
> ./utils/fingerprint/fingerprint.py restore -f
I've brought back the old section about fingerprint.py for 7.8.*
to the GettingTheSources wiki page, updated it, to the best
of my knowledge, and added the info from the email below.
Please correct the section if I mixed up anything. I think,
for as long as 7.8.* is in widespread use, the section h
tt may be that GHC 7.8 optimizes the program better.
Compile with -O0 and see if it runs out of memory, too.
If so, you can just optimize the program by hand.
I'd suggest making a heap profilie with -O0 or in GHC 7.6
and finding out where the memory goes.
Of course, it's possible you've hit a comp
On Sat, Dec 13, 2014 at 8:53 PM, Carter Schonwald
wrote:
> Thomas and I have found some bugs in HPC on OSX, and we're in the midst of
> tracking those down,
You mean these are regressions? If they are introduced
in one of the non-blocker fixes in 7.8.4, we can probably
just revert them. Anyway, t
OK. In that case, let's remember to get *that* version of cabal into 7.8.4.
/me conditions himself with chocolate to help the remembering
On Sat, Dec 13, 2014 at 11:02 PM, Thomas Tuegel wrote:
> On Sat, Dec 13, 2014 at 3:56 PM, Mikolaj Konarski
> wrote:
>> On Sat, Dec 13
This looks like the result of the new cool patch by SPJ
that detects redundant constraints.
IIRC, it was supposed to be added to -Wall, but disabled
for validate, at least for packages out of our control.
___
ghc-devs mailing list
ghc-devs@haskell.org
htt
Resending, since Roman's and Kyril's email addresses were mangled/missing.
On Mon, Feb 16, 2015 at 3:43 PM, Simon Peyton Jones
wrote:
> Darren
>
>
>
> Excellent! We have a Windows Task Force, consisting roughly of the folk in
> cc. So they would be the first group to ask.
>
>
>
> (I think it wo
Yay! Is that related to the following ("I also want to investigate
making INLINE pragmas fire in the "gentle" phase, on the grounds
that that's what the programmer said.")?
https://ghc.haskell.org/trac/ghc/ticket/12603#comment:30
On Fri, Feb 17, 2017 at 5:41 PM, Simon Peyton Jones via ghc-devs
> On the same topic, I also wrote a blog post simply explaining the
> essential things to know
> about the inliner and specialiser as I don't think they are generally
> appreciated. Comments welcome!
>
> http://mpickering.github.io/posts/2017-03-20-inlining-and-specialisation.html
LGTM. I'd propos
> GHC tries hard NOT to choose an INLINE function as a loop breaker. But if
> you write
>
> f x = if ... then 0 else (f x')
> {-# INLINE f #-}
>
> then the only possible loop breaker is 'f', so GHC has to choose it.
Indeed.
> What else would you suggest?
A warning would be very welcome. Given
Hello,
I've had a similar problem that's been fixed in 8.2.1:
https://ghc.haskell.org/trac/ghc/ticket/12603
You can also use some extreme global flags, such as
ghc-options: -fexpose-all-unfoldings -fspecialise-aggressively
to get most the GHC subtlety and shyness out of the way
when experiment
On Wed, Mar 7, 2018 at 8:10 AM, Phyx wrote:
> In my experience to get a 32 bit build you need to
> install the full 32bit msys2. Not just the 32bit compiler in the 64 bit
> msys2 (two installs can co-exist).
That's also my experience on appveyor (but I'm not compiling GHC itself):
https://github
> What about #15005? It is closed as fixed but not mentioned in the
> release notes.
The fix was merged and included in the release. It's on the list of commits at
https://github.com/ghc/ghc/commits/ghc-8.4.2-release
* In Exitify, zap idInfo of abstracted variables (fixes #15005)
Cheers,
Mikolaj
On Tue, Jan 8, 2019 at 2:10 AM Gabor Greif wrote:
>
> Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the
> inliner to respect the pragma?
Yes:
https://gitlab.haskell.org/ghc/ghc/commit/b9b1f99954e69f23e9647d00e048938d5509ec14
But it's not on 8.6 branch (yet?).
__
> Either way, I can’t see any comments whatsoever! It says 5/5 discussions
> resolved, but I can’t actually see them. There is not “toggle discussion”
> button anywhere.
Hello Simon,
Just below "5/5 discussions resolved" I can see 5 discussions
with “toggle discussion” link to the right of ea
> Looking here
> https://gitlab.haskell.org/ghc/ghc/merge_requests/116//diffs
> I see literally NO discussions with a "toggle discussion" button. Indeed if
> I search for "toggle" I get no hits.
Oh, I see, you are right with respect to the link you cited now.
None of the buttons help, just as yo
> Yes, in the discussion tab I can. But of course that is out of context; you
> just get a little (non-expandable) snippet.
I lack the gitlab experience to push this any further, but I guess
an "unresolve discussion" button/checkbox would at least be
a stop-gap measure. I couldn't see such a but
On Mon, Jan 14, 2019 at 10:28 AM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:
>
> I suppose we could issue guidance NEVER to resolve a discussion, but that
seems like the wrong conclusion.
It seems gitlab's "resolve discussion" action is supposed to mean
"I think nobody needs to
Richard, what you propose totally makes sense to me.
Simon, Sylvain, indeed, when I click "toggle comments for this file"
in the first patch, I can see not only an avatar, but the whole comment.
However, this is only one comment, in both diffs, out of many,
which adds to the confusion. May it be c
Hi George,
Since many versions of cabal, `install` only installs executables, not
libraries, so if that worked for you, you must have had an old version
of cabal.
Please see https://github.com/haskell/cabal/issues/6481 for some
context and to help you find a new workflow that works for you
(ideal
nstall the workaround for ghc-pkg is to add the option
> > "-f $HOME/.cabal/store/ghc-9.2.1/package.db" to the end of the command
> > "ghc-pkg list". For compilation the workaround is to add "-package-db
> > $HOME/.cabal/store/ghc-9.2.1/packa
Talking as a Haskell user, but also a cabal maintainer:
the Haddock work Hécate describes is crucial for the health
and efficiency of the whole ecosystem and the sooner
we can start it, the less drag it's going to have on the rest.
Given that GHC expertise is not necessary for many
of the tasks in
> I once tried to generate ETAGS and use them from Emacs (with plain
> haskell-mode): this
> was quite nice. As Moritz, I didn't use much above syntax coloring, but ETAGS
> allowed jumping to definitions, which is important. Maintaining tags wasn't
> fun,
> on the other hand.
Package https://hac
On Sat, Aug 12, 2023 at 5:20 PM Brandon Allbery wrote:
>
> The warning sounds correct to me: `Maybe` has two constructors?
It says at
https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/pragmas.html#unpack-pragma
"Since 9.6.1, data types with multiple constructors can also be
unpacke
35 matches
Mail list logo
