Hello,
Note: you actually don't have to backport anything. Leave it for people
how are interested in LTS release.
As haskell enthusiast, I like all the features GHC comes with each
release. But as working haskell programmer I'm tired. All my code I
wrote at work will probably work with ghc-6.8,
Just for the heck of it, I tried out an implementation of scanl using
Joachim Breitner's magical oneShot primitive. Using the test
scanlA :: (b - a - b) - b - [a] - [b]
scanlA f a bs = build $ \c n -
a `c`
foldr (\b g x - let b' = f x b in (b' `c` g b'))
(const n)
bs
Hi Arash,
Thanks for your reply.
I'm interested in stepping through the compiler part (Lexer, Parser, etc...) of
GHC for now.
Thanks for the link to the commentary. I'm going through it right now.
---
Hi Omar,
You might want to narrow your scope to one part of GHC. For example, I
mostly
Thanks for this debate. (And thank you Austin for provoking it by articulating
a medium term plan.)
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
On 2014-10-07 at 10:57:00 +0200, Simon Peyton Jones wrote:
I suppose I will have to look at this. But I have no clue how to do so.
D202 itself seems to be a very small patch (only ten lines or so), so
presumably it applies on top of some other patch? But what?
Someone said I could use
On Tue, Oct 7, 2014 at 10:12 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
| 8960 looks rather serious and potentially makes all of 7.8 a no-go
| for some users.
I think this is the big issue. If you look at all the related bugs linked
from #8960, lots of users are affected. I think
I re-targeted some of the bugs that were obviously the same SpecConstr
issue to 7.8.4. There are a few others that should probably also be
re-targeted, but I couldn't tell from a quick scan of the long comment
threads.
Looking at the 7.8.4 status page, it's now quite clear that the SpecConstr
bug
Aha, that helps. And looking further at https://phabricator.haskell.org/D202,
I can see under Revision update history that there are four diffs all stashed
in this on Phab ticket. (That contradicts my previous model which was one patch
per Phab ticket; people have been complaining about that.)
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 be
Wait, isn't call arity analysis meant to do this by itself now?
On 7 October 2014 17:05, David Feuer david.fe...@gmail.com wrote:
Just for the heck of it, I tried out an implementation of scanl using
Joachim Breitner's magical oneShot primitive. Using the test
scanlA :: (b - a - b) - b - [a]
Ugh. Arc is not easy to use :-/ Indeed 3e17822 does not seem to be in the
revision on phab,
although it exists in my local tree. I just pushed a fixed to Phab. Simon, does
`arc patch D202`
work now?
Herbert, remember how I complained on IRC that `arc diff` does not
automatically recognize
On 10/1/2014 6:25 AM, Simon Peyton Jones wrote:
·[...] The important thing is that it
should be reproducible, and not dependent on the particular Cygwin or
gcc or whatever the that user happens to have installed.
Exactly. So how about setting up a build server using msys2?
I guess the
First off, I just wanted to tell everyone - thank you for the feedback!
I actually left these tickets in their place/milestones just in case
something like this popped up, so I wouldn't have to undo it later. It
seems like there's actually a fair amount of support for 7.8.4, where
before we
In direct answer to your question, there's not a great way to step through the
code. As far as I know, there isn't a way to load GHC into GHCi. Personally, I
think a lot about the type-checker and so use -ddump-tc-trace a lot. You can
line up the output with the code to see what is going on.
Much better thank you.
Now I get as far as
compiler/typecheck/TcTyClsDecls.lhs:421:26: Warning:
Pattern match(es) are non-exhaustive
In a case alternative: Patterns not matched: KindedTyVarSig (L _ _)
No time to investigate right now.
=
New workflow question for
2014-10-07 15:04 GMT+02:00 cg chengan...@gmail.com:
I guess the current two build server are all Cygwin based, they are
failing at the same permission issue at early building stage, it prevents
checking out the real problem. It seems msys2 (or msys) seldom has
such issue.
For what it is
Yes, and it does a very good job in many cases. In other cases, it's
not as good.
On Tue, Oct 7, 2014 at 7:59 AM, Sophie Taylor sop...@traumapony.org wrote:
Wait, isn't call arity analysis meant to do this by itself now?
On 7 October 2014 17:05, David Feuer david.fe...@gmail.com wrote:
Just
I personally don't have a problem writing Docbook, and one problem
with moving to lightweight markup is it becomes a bit harder to
keep your markup semantic.
Edward
Excerpts from Herbert Valerio Riedel's message of 2014-10-07 09:20:43 -0600:
Hello GHC Developers GHC User's Guide writers,
I
On 10/07/2014 02:32 AM, p.k.f.holzensp...@utwente.nl wrote:
But that would only work on 64 bit systems, right?
Yes, this approach to a parallel GHC would only work on 64-bit machines.
The idea is, I guess, that we're not going to see a massive demand for
parallel GHC running on multi-core
On Tue, Oct 7, 2014 at 6:25 PM, Edward Z. Yang ezy...@mit.edu wrote:
I personally don't have a problem writing Docbook, and one problem
with moving to lightweight markup is it becomes a bit harder to
keep your markup semantic.
Edward
Why would this be a problem with asciidoc? All asciidoc
On Tue, Oct 7, 2014 at 11:24 AM, Austin Seipp aus...@well-typed.com wrote:
The more annoying bit is it will incur an extra dependency for GHC
documentation - which, remember, is part of ./validate - but that's
life, perhaps.
Docbook is a fairly large dependency in my experience?
--
brandon
On Tue, Oct 7, 2014 at 1:32 AM, p.k.f.holzensp...@utwente.nl wrote:
Yes, this approach to a parallel GHC would only work on 64-bit machines. The
idea is, I guess, that we're not going to see a massive demand for parallel
GHC running on multi-core 32-bit systems. In other words; 32-bit systems
Just for the record - I'm very much in favor of this. +1 from me.
I think the one-time cost is very low for the most part, if the end
result is a significantly more readable users guide to hack on.
IMO, I don't particularly care whether we use Sphinx or AsciiDoc. The
nice thing about AsciiDoc
I don't really care too much about the size of the dependency (since
99.9% of time it's automated anyway via some package manager). My
remark was more referring to the number of dependencies increases by 1
no matter what. :)
But like I said, that's just life, and I frankly don't see this part
as
Hi,
On 2014-10-03 23:35, Austin Seipp wrote:
..
Here are the major patches on Phabricator still needing review, that I
think we'd like to see for 7.10.1:
- D168: Partial type signatures
..
As Austin said, our patch implementing Partial Type Signatures is still
up for code review on
Wait, wait, wait! I wasn't talking about a parallel *runtime*. Nothing changes
there. All I'm talking about is something that is a very old issue that never
got added / solved / resolved. Somewhere on the commentary, or the mailing
list, I seem to recall that the generation of Uniques was the
From: mad@gmail.com mad@gmail.com on behalf of Austin Seipp
aus...@well-typed.com
So I assume your change would mean 'ghc -j' would not work for 32bit.
I still consider this a big limitation, one which is only due to an
implementation detail. But
Simon,
I finally managed to implement that for major NCG backends.
Phabricator revision is here: https://phabricator.haskell.org/D252
Here is a link to the review you did before:
https://github.com/Yuras/ghc/commit/7295a4c600bc69129b6800be5b52c3842c9c4e5b
I don't have implementation for mac os
On Tue, Oct 7, 2014 at 11:25 AM, cg chengan...@gmail.com wrote:
On 9/16/2014 4:57 AM, Gintautas Miliauskas wrote:
msys2 seems to be in good shape and should probably be promoted to the
primary suggested method to build ghc on Windows. Let's look into that
once the new build instructions have
Hi,
Am Montag, den 06.10.2014, 19:32 +0200 schrieb Joachim Breitner:
Am Montag, den 06.10.2014, 17:54 +0200 schrieb Tuncer Ayaz:
By the way, while the Github team has no public ticket system, they
are very responsive when you send them feature requests or, say,
explain where the review
To complement what Thomas said: Phabricator currently claims that the
patch is not building, but if I understand Thomas correctly, this is
the consequence of a limitation of the Phabricator builder which is
not treating the haddock part of the patch correctly.
So to reiterate: the partial type
in some respects, having fully deterministic builds is a very important
goal: a lot of tooling for eg, caching builds of libraries works much much
better if you have that property :)
On Tue, Oct 7, 2014 at 12:45 PM, p.k.f.holzensp...@utwente.nl wrote:
Dear Carter, Simon, et al,
(CC'd SPJ on this explicitly, because I *think* he'll be most knowledgeable on
some of the constraints that need to be guaranteed for Uniques)
I agree, but to that end, a few parameters need to become clear. To this end,
I've created a Phabricator-thing that we can
Is the wiki page up to date?
https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures
I'd move the Constraint Wildcards bit out to an appendix or delete altogether
-- it's a distraction since it's not part of the design.
Named wildcard are described as a fourth form but actually it's third
I've cleaned up the main Windows build
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows page,
moved MSYS2 instructions there, moved out legacy instructions and added
backlinks / warnings / redirects. It would be great if someone could go
through, verify the instructions and make
Ok, if the ghc devs decide to do a 7.8.4 release, I will explicitly commit
to helping backport patches.
However, I don't know how to do so. Therefore, I'm going to ask Austin (as
he's probably the most knowledgeable) to update the 7.8.4 wiki page with
the process people should use to contribute
By the way, I've noticed that ghc occasionally segfaults during Windows
builds, like this:
inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H64m
-O0 -fasm-hide-all-packages -i -iutils/hsc2hs/.
-iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen
I agree a section show stoppers is a good idea, in parallel would it make
sense to use the priority highest for tickets that we consider
showstoppers?
Austin did a great of explaining the difficulties of backporting fixes, my
reaction is that we have to have higher quality releases so that
On 10/8/2014 1:03 AM, Austin Seipp wrote:
I hide 'empty' and 'foldr' at importing point and the code compiles.
Has anyone see the same issues?
Ugh, this is some fallout I thought we had fixed, but apparently not.
I'll fix it shortly, thanks.
[...]
Why does ghc-stage1.exe use so much
39 matches
Mail list logo
