On 2014-10-10 at 09:19:31 +0200, Páli Gábor János wrote:
> Looks one of the recent commits broke the x86 builds on multiple
> platforms [1][2][3]. The common error message basically is as
> follows:
>
> rts/Linker.c: In function 'mkOc':
> rts/Linker.c:2372:6:
> error: 'ObjectCode' has no memb
On 2014-10-09 at 07:15:13 +0200, Páli Gábor János wrote:
> 2014-10-07 17:02 GMT+02:00 Páli Gábor János :
>> 2014-10-07 15:04 GMT+02:00 cg :
>>> 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
>>> check
On 2014-10-08 at 14:00:05 +0200, Alan & Kim Zimmerman wrote:
[...]
> Should this go into Trac?
Fwiw, there is a version "7.9" you can select when writing a Trac ticket
for the very purpose to file bugs against GHC HEAD.
[...]
> The file being compiled is
>
> ---
On 2014-10-08 at 10:49:33 +0200, Jan Stolarek wrote:
>> Therefore I'd like to hear your opinion on migrating away from the
>> current Docbook XML markup to some other similarly expressive but yet
>> more lightweight markup documentation system such as Asciidoc[1] or
>> ReST/Sphinx[2].
> My opinion
On 2014-10-08 at 02:13:01 +0200, Carter Schonwald wrote:
> the checkout process for the 7.8 branch is a bit involved (and NB: you
> really want to use a different tree than one for working on head, the
> checkout process is different
> )
>
> $ git clone -b ghc-7.8 git://git.haskell.org/ghc.git ghc-
Hello,
On 2014-10-08 at 02:34:50 +0200, George Colpitts wrote:
> 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?
I think, they are marked 'highest' already
Btw, one could additionally add
On 2014-10-08 at 04:28:50 +0200, cg wrote:
[...]
> After cloning ghc repository, I switch every sub-module to Master (it is
> usually HEAD) branch.
Why are you doing that? :-)
[...]
> Now after cloning ghc repository, if I don't switch to any branch --
> 'git branch'
> will show all submodule
Hello GHC Developers & GHC User's Guide writers,
I assume it is common knowledge to everyone here, that the GHC User's
Guide is written in Docbook XML markup.
However, it's a bit tedious to write Docbook-XML by hand, and the XML
markup is not as lightweight as modern state-of-the-art markup langu
On 2014-10-07 at 15:04:18 +0200, cg wrote:
[...]
> 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.
Btw, while I fina
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 2014-10-06 at 11:50:03 +0200, Malcolm Wallace wrote:
> On 6 Oct 2014, at 10:28, Herbert Valerio Riedel wrote:
>
>> As I'm not totally sure what you mean: Assuming we already had decided
>> years ago to follow LTS-style, given GHC 7.0, 7.2, 7.4, 7.6, 7.8 and the
>>
On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote:
[...]
> The idea behind an LTS-GHC would be to continue bug-fixing on the
> LTS-version, even if newer major versions no longer get bug-fixing
> support. To some extent, there will be redundancies (bugs that have
> disappeared i
Hello,
On 2014-10-05 at 14:03:41 +0200, Joachim Breitner wrote:
> Am Sonntag, den 05.10.2014, 13:08 +0200 schrieb Herbert Valerio Riedel:
>> On 2014-10-05 at 12:56:28 +0200, Joachim Breitner wrote:
>>
>> [...]
>>
>> > I think the advantage could outwei
On 2014-10-05 at 04:51:41 +0200, Richard Eisenberg wrote:
> I've just finished reading this:
> http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/
>
> For better or worse, I don't read reddit often enough to hold a
> conversation there, so I'll ask my qu
On 2014-10-03 at 17:29:31 +0200, Simon Peyton Jones wrote:
> Perhaps, yes, it is Python 3. I don't know. Could someone revert to
> make it work again, please?
Fyi, I can't reproduce this specific problem on Cygwin at least (I don't
have any working pure Msys2 environment yet (still working on it)
On 2014-10-02 at 09:49:11 +0200, Simon Peyton Jones wrote:
> Herbert says (in bold font) "do not ever use sync-all", in this post
> http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/.
>
> If that's really true, we should either nuke it altogether, or ch
tag, den 28.09.2014, 13:07 + schrieb g...@git.haskell.org:
>> commit e5cca4ab246ca2d1ecdd7c39eefd3157547cb6aa
>> Author: Herbert Valerio Riedel
>> Date: Sun Sep 28 13:02:53 2014 +0200
>>
>> Extend `Foldable` class with `length` and `null` met
On 2014-09-29 at 10:43:28 +0200, Andreas Abel wrote:
> Indeed, being able to introduce a short name for the current module,
> or having a fixed short name like 'This' or 'Self' would be neat.
>
> The standard workaround for your example would be
>
> import Prelude hiding (length,null)
That won't
Hello *,
Here's a situation I've encountered recently, which mades me wish to be
able to define a local alias (in order to avoid CPP use). Consider the
following stupid module:
module AnnoyinglyLongModuleName
( AnnoyinglyLongModuleName.length
, AnnoyinglyLongModuleName.null
Hello!
I can only address a small subset of your comments as I don't usually
develop on Windows and hence lack any significant Windows experience...
On 2014-09-27 at 23:04:38 +0200, Gintautas Miliauskas wrote:
[...]
> 2. Since the msys2 setup instructions are so simple and linear, perhaps it
>
On 2014-09-27 at 21:46:13 +0200, Karel Gardas wrote:
> Hi Mikhail,
>
> On 09/27/14 09:09 PM, Mikhail Glushenkov wrote:
>> On 27 September 2014 20:19, Karel Gardas wrote:
>>>
>>> [...]
>>> Could you be so kind and revert this patch or fix it to also work on
>>> Solaris? For Solaris the change shoul
On 2014-09-25 at 13:34:16 +0200, Daniel Trstenjak wrote:
[...]
> One compromise could be, that additional commatas in literal lists
> are only allowed at the beginning and at the end.
...another idea could be to make it a separate Pragma
(e.g. ExtraCommasLists) if there's a chance of ListSection
On 2014-09-25 at 11:18:01 +0200, Simon Peyton Jones wrote:
> That would suggest continuing to make extra commas illegal in literal
> lists, for now anyway. That’s a conservative choice, which is usually
> the side to err on when it’s a toss-up.
I'd just like to point out, that lists are somethin
On 2014-09-24 at 08:50:22 +0200, Edward Kmett wrote:
> I'm personally of the "it should be a language extension like everything
> else" mindset.
Me too. Mostly for being able to have more useful error messages with
older GHCs and other Haskell parsers.
Because if it's a lang-ext pragma, you hav
On 2014-09-22 at 14:31:10 +0200, Alexander Berntsen wrote:
> Forwarding this & my reply to the ML as well,
>
>
> On 22/09/14 14:27, David Luposchainsky wrote:
>> +1. While you're at it, you may also want to consider allowing
>> leading commas for the folks that write their exports/records "the
>> o
On 2014-09-10 at 11:53:05 +0200, Simon Peyton Jones wrote:
> I accidentally created a branch (in the main repo) called
>origin/origin/wip/new-flatten-skolems-Aug14
> I was trying to make a local branch to track the existing
> origin/wip/new-flatten-skolems-Aug14, but only succeeded
Hello Simon,
On 2014-08-19 at 00:01:17 +0200, Simon Peyton Jones wrote:
[...]
> But you can probably write the code in such a way as to be mostly
> independent (eg explicit UNPACK rather than rely on
> -funbox-strict-fields), or assume that some things won't happen
> (e.g. souce module will not
Hello *,
I'm a bit stuck with the wired-in type aspect of integer-gmp2 and was
hoping someone with more experience in this area could provide direction
on how to properly register the data definition
data Integer = SI#Int#
| Jp# {-# UNPACK #-} !BigNat
On 2014-08-16 at 16:59:51 +0200, Mateusz Kowalczyk wrote:
[...]
> Herbert kindly updated the sync-all script that
> defaults to the new branch so I think we're covered.
Minor correction: I did not touch the sync-all script at all. I merely
declared a default branch in the .gitmodules file:
On 2014-08-14 at 00:09:40 +0200, Mateusz Kowalczyk wrote:
[...]
> I don't know what the GHC branch name will be yet. ‘ghc-head’ makes most
> sense but IIRC Herbert had some objections as it had been used in the
> past for something else, but maybe he can pitch in.
I had no objections at all to t
On 2014-08-10 at 12:17:56 +0200, Johan Tibell wrote:
[...]
> First, doing that was in itself a bit of a pain. 'arc diff' didn't do the
> right thing and included some random commit(s) instead of my single commit
> in my feature branch. Perhaps it tried to diff against origin/master or
> something
On 2014-08-08 at 09:42:14 +0200, Simon Hengel wrote:
> On Fri, Aug 08, 2014 at 09:00:21AM +0200, Herbert Valerio Riedel wrote:
>> Just to clarify, as the last sentence contains a double-negation: GHC
>> devs continue pushing to github.com/haddock.git's `master` branch to
>
Hi Mateusz,
I'm mostly interested in understanding the Git-level/workflow changes,
so here's a few questions to improve my understanding of what's changing
related to Git:
On 2014-08-08 at 07:25:01 +0200, Mateusz Kowalczyk wrote:
[...]
> I do all the work and I think it's a 1 line change in sync
The GHC User's Guide[1] says:
| There is one (apparent) exception to this general rule that a bang
| only makes a difference when it precedes a variable or wild-card: a
| bang at the top level of a let or where binding makes the binding
| strict, regardless of the pattern. (We say "apparent" exc
Hello Simon,
On 2014-07-31 at 10:53:20 +0200, Simon Marlow wrote:
[...]
>> rts: add Emacs 'Local Variables' to every .c file
>>
>> This will hopefully help ensure some basic consistency in the forward by
>> overriding buffer variables. In particular, it sets the wrap length, the
>
On 2014-07-29 at 14:13:22 +0200, Richard Eisenberg wrote:
> Are folks very keen to have *warning-free* compilation on several GHC
> versions? Personally, I would aim for warning-free compilation on a
> most recent version, and otherwise successful compilation on older
> versions.
IMO: In typical
On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where …
>
> Is the syntax somewhat flexible in where the pragma can be placed?
> For example, some might prefer
>
> {-# OVERLAPPING #-}
> instance Show [Char] where …
This variant may a
Hello *,
While working on integer-gmp2 I noticed that there seems to be redundant
code between rts/StgPrimFloat.c and integer-gmp. Specifically, there's a
void
__decodeDouble_2Int (I_ *man_sign, W_ *man_high, W_ *man_low, I_ *exp,
StgDouble dbl);
C implementation which
Hello!
On 2014-07-29 at 08:25:15 +0200, Dr. ERDI Gergo wrote:
> Is there a good reason we have a single monolithic .gitignore file in
> testuiste/ instead of one per directory? It just feels so
> unnecessarily burdensome to maintain it compared to just putting four
> lines in a new .gitignore file
Hello Niklas,
On 2014-07-22 at 23:38:07 +0200, Niklas Larsson wrote:
> I can do both 32 and 64-bit builds.I started with 32 bits.
Both would be interesting!
> I got
[...]
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp2 ... linking ... ghc-stage2.exe: unable to l
On 2014-07-22 at 13:33:04 +0200, Niklas Larsson wrote:
> I can test on Windows.
great! Are you using the 32bit or 64bit compiler?
All you'd need to do is 'git checkout' the wip/T9281 branch, add the line
INTEGER_LIBRARY=integer-gmp2
at the end of mk/build.mk (and 'BuildFlavour=quick' should
Hello *,
As some of you may have already noticed, there's an attempt[1] in the
works to reimplement integer-gmp in such a way to avoid overriding GMP's
internal memory allocator functions, and thus make it possible to link
GHC/integer-gmp compiled programs with other components linked to libgmp
wh
On 2014-07-17 at 08:54:32 +0200, Simon Peyton Jones wrote:
[...]
> - it's at the bottom of a long page, most of which is irrelevant if you use
> ./sync-all (I think??)
Fwiw, the page was written to be a `./sync-all`-agnostic on purpose (in
fact, ./sync-all isn't mentioned only once for pre-subm
On 2014-07-14 at 09:34:07 +0200, Simon Peyton Jones wrote:
> Is it possible to stop spam on GHC's Trac?
A few days ago, bots/users registering via @yahoo.com addresses managed
to break the (rather simple) text-based algebraic captcha. I guess we
need to up the game and maybe switch to a (simple) H
On 2014-07-12 at 17:40:07 +0200, Simon Marlow wrote:
> Yes, this will cause problems in some modes, namely -debug and -prof
> that need to be able to scan the heap linearly.
...and I assume we don't want to fallback to a non-zerocopy mode for
-debug & -prof in order avoid distorting the profilin
On 2014-07-13 at 05:52:09 +0200, Bryan O'Sullivan wrote:
[...]
> haddock 2.14.3 that ships with it seems to be quite broken. Perhaps it's a
> bad interaction with cabal, it's hard to say from the outside, but here are
> some details.
>
> Here's the kind of error I get from haddock when I try to u
Hello Simon (et al.)
While experimenting with refactoring/improving integer-gmp, I'd like to
represent a GMP number just by a ByteArrays# (and thus save a redundant
limb-count field). However, for that I'd need an efficient way to resize
a MutableByteArray# for the result value in case its initial
On 2014-07-11 at 14:12:14 +0200, Joachim Breitner wrote:
[...]
> heh, fat chance. Travis is unable to check out the repository from
> github, because the submodule URL points to something invalid:
>
> Cloning into 'libraries/Cabal'...
> fatal: remote error:
> ghc/packages/Cabal is not a valid
Hello Joachim,
On 2014-07-11 at 12:36:23 +0200, Joachim Breitner wrote:
> with all packages as submodules, ghc-complete (which is basically a git
> repository tracking the „fingerprint“ of the main repository) is
> obsolete. So we could move the travis-checking of the main line to run
> on the ghc
On 2014-07-10 at 08:50:57 +0200, Austin Seipp wrote:
> Hi all,
>
> After all the paranoia and double-checking, the source tarballs are online:
>
> https://www.haskell.org/ghc/dist/7.8.3/
...and here are the Ubuntu 12.04/12.10/13.04/13.10/14.04 compatible
binary .deb packages for i386 and x86_64:
On 2014-07-07 at 03:40:17 +0200, William Knop wrote:
[...]
> I think using Jenkins may be a step in the right direction for a few reasons:
>
> • there are hundreds of supported plugins [1] which cover notifications, code
> review [2], cloud computing services, and so on
> • there is quite a lot
On 2014-06-30 at 08:45:57 +0200, Jan Stolarek wrote:
> Herbert, all,
>
> I just pulled the new HEAD and have a question which I believe was not
> addressed so far. In my
> work on the GHC tree I never pulled the dph subrepo because the only thing it
> adds for me is
> extra build time (of cours
On 2014-06-30 at 22:27:16 +0200, Iavor Diatchki wrote:
> Sorry about this. It would appear that I am not allowed to push to the
> `haddock` repo, so I've attached a patch, for someone with permissions to
> apply.
>
> Also, could I be given permissions to modify haddock, since GHC and haddock
> ar
Hi,
Fyi, this changeset seems to have broken ./validate:
utils/haddock/src/Haddock/Interface/Rename.hs:449:11: Warning:
Fields of ‘ClsInstDecl’ not initialised: cid_overlap_mode
In the first argument of ‘return’, namely
‘(ClsInstDecl
{cid_poly_ty = ltype', cid_bi
cording to
http://www.gostai.com/downloads/urbi-sdk-2.0/doc/urbi-sdk.htmldir/faq.html#x22-10400014.1.4
and other results you may get if you google for that error
>
> Thanks,
>
> Gabor
>
> On 6/28/14, Herbert Valerio Riedel wrote:
>> On 2014-06-28 at 13:49:15 +02
On 2014-06-28 at 13:49:15 +0200, Gabor Greif wrote:
> Hi herbert,
>
> I followed your instructions, and one of my repos converted well:
>
> e8a901fddc88c6560af34e18a5201deeb8d51557 libraries/stm
> (stm-2.4.3-release-3-ge8a901f)
>
> the other gave:
>
> -e8a901fddc88c6560af34e18a5201deeb8d51557 libr
On 2014-06-28 at 07:48:16 +0200, Manuel M T Chakravarty wrote:
> I noticed that the Cabal package doesn’t have a branch for ghc-7.8:
>
> http://git.haskell.org/packages/Cabal.git
>
> Is that intended?
A ghc-7.8 branch is not really needed, as Cabal is registered as
submodule in ghc.git's ghc-7.8
Hi Simon,
On 2014-06-26 at 14:13:08 +0200, Simon Peyton Jones wrote:
> Did you follow up with more specific instructions?
>
> In particular,
> - how do I bring an existing clean tree up to date?
I tought I addressed that right at the start of
http://www.haskell.org/pipermail/ghc-devs/2014-June
On 2014-06-26 at 13:42:47 +0200, Karel Gardas wrote:
> On 06/26/14 12:37 PM, Johan Tibell wrote:
[...]
>> Also, how do I repro this if I don't have a x86 machine lying around?
>> Have people been successful working on these kind of issues in a VM?
>
> My simplest way is to install VirtualBox and i
ecifically means the submodule is not initialized
properly)
For further information, please read the current documentation at
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
and let me know what all needs to improved.
On 2014-06-25 at 09:47:04 +0200, Herbert Valerio
Hello GHC Devs!
In order to not drag this out any longer, I'll completing the submodule
conversion in the next few hours by converting the remaining sub-repo
packages into proper submodules.
This is represents phase 1 of the reorganization (phase 2 comprises
officially transitioning the push-url
Fyi, this also broke on the nightly PPA builds (which made me notice it):
https://launchpadlibrarian.net/178475113/buildlog_ubuntu-precise-i386.ghc-head_7.9.20140624-1_FAILEDTOBUILD.txt.gz
Cheers,
hvr
On 2014-06-25 at 05:42:57 +0200, Builder wrote:
> validator1-linux-x86-head (Linux/x86 HE
On 2014-06-21 at 13:35:28 +0200, Herbert Valerio Riedel wrote:
> On 2014-06-21 at 13:09:31 +0200, Edward Z. Yang wrote:
>> As long as you check the performance impact on 32-bit, sounds good to
>> me.
>
> What's the currently accepted/canonical lexer/parser benchmark to e
On 2014-06-21 at 13:09:31 +0200, Edward Z. Yang wrote:
> As long as you check the performance impact on 32-bit, sounds good to
> me.
What's the currently accepted/canonical lexer/parser benchmark to evaluate that?
___
ghc-devs mailing list
ghc-devs@haske
Hello Simon (et al.),
While doing #9224[1] as a finger-exercise to extend the lexer to support
base-2 integer literals, I got stuck on the lexer extension map being
represented as an 'Int', which (in GHC) is only guaranteed to hold least
32bits.
-- for reasons of efficiency, flags indicating lang
On 2014-06-09 at 18:08:20 +0200, git-4Dsf34iY/nkouohngz6...@public.gmane.org
wrote:
[...]
> +
> +
> +The libraries haskeline,
> +xhtml, terminfo,
> +transformers, and
> +haskeline are now exported and
> +registered in t
Hello Simon,
On 2014-06-10 at 10:25:46 +0200, Simon Peyton Jones wrote:
[...]
> We physically include very selective chunks of MinGW in a GHC Windows
> distribution
> - so that users don't need to install MinGW
> - so that GHC doesn't break just because a user has
> a different version of Min
On 2014-06-08 at 10:00:46 +0200, Joachim Breitner wrote:
[...]
>> I'm specifically looking for builds off of the 7.8 branch so I can
>> start testing point releases.
>
> Then I guess the easiest would be if Herbert would add that to his
> PPA.
Fwiw, there have been already 'ghc-7.8.3' packages i
On 2014-06-06 at 14:11:21 +0200, Simon Peyton Jones wrote:
> I ran that command and it didn't complain. No idea whether it worked or not
> though! This now appears in .gitconfig
>
> [url "ssh://g...@github.com/haskell/haddock.git"]
> pushInsteadOf = ssh://g...@ghc.haskell.org/haddock.git
>
On 2014-06-06 at 14:07:44 +0200, Simon Peyton Jones wrote:
> | Short story: you have to use ssh://g...@github.com/haskell/haddock.git as
> | push-url
> |
> | git push ssh://g...@github.com/haskell/haddock.git
> |
> | where refers to the kind of branch-update operation you want
> | to push, li
On 2014-06-06 at 13:47:03 +0200, Simon Peyton Jones wrote:
[...]
> To ssh://g...@ghc.haskell.org/haddock.git
PS: you could also try to configure the following (assuming your Git is
new enough):
git config --global \
url."ssh://g...@github.com/haskell/haddock.git".pushInsteadOf \
ssh
On 2014-06-06 at 13:47:03 +0200, Simon Peyton Jones wrote:
> I'm trying desperately to follow the instructions on
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
> for how to update haddock to follow a small change to GHC.
> I've checked out the haddock master, made my pat
On 2014-05-29 at 09:17:58 +0200, Simon Marlow wrote:
>> While I refactored the ghc code base to declare LANGUAGE pragmas
>> locally, rather than via -X-flags on the GHC commandline, I've noticed
>> there were a couple of places where NondecreasingIndentation grammar was
>> used.
>>
>> What's the c
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, wouldn't the version of base b
On 2014-05-27 at 12:13:18 +0200, Yitzchak Gale wrote:
> 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 kn
Hi,
On 2014-05-27 at 10:06:39 +0200, Austin Seipp wrote:
[...]
> The question is: when should we do the release? There are several bugs
> there that seem quite problematic for users - #9045, #7097, #9001,
> #8768 and #9078 in particular.
Personally, I'd vote for a soon-ish 7.8.3 release for thi
On 2014-05-25 at 08:50:21 +0200, Dr. ERDI Gergo wrote:
> Hi,
>
> I've just tried pushing a commit to the Haddock repo on git.haskell.org:
[...]
> So how do I get my commit (which is needed for a patch to GHC proper)
> into the Haddock repo?
short story: push to g...@github.com:haskell/haddock.gi
Hello again,
...while experimenting with TypeLits I stumbled over the following
simple case failing to type-check with GHC 7.8.2:
{-# LANGUAGE DataKinds, GADTs #-}
data List l t where
Nil :: List 0 t
Cons :: { lstHead :: t, lstTail :: List l t } -> List (l+1) t
with th
Hello *,
I've been experimenting with the code from the "Dependently Typed
Programming with Singletons" paper[1] from the following is derived (modulo some
irrelevant renamings):
{-# LANGUAGE TypeOperators, DataKinds, GADTs, TypeFamilies #-}
module CheckedList where
data Nat =
Hello GHC devs,
While I refactored the ghc code base to declare LANGUAGE pragmas
locally, rather than via -X-flags on the GHC commandline, I've noticed
there were a couple of places where NondecreasingIndentation grammar was used.
What's the current consensus on the use of NondecreasingIndentatio
On 2014-05-13 at 16:16:12 +0200, Joachim Breitner wrote:
[...]
> commit 4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba
> Author: Simon Peyton Jones
> Date: Tue May 13 13:15:45 2014 +0100
>
> Lint should check that TyConAppCo doesn't have a synonym in the
On 2014-05-10 at 18:30:40 +0200, Joachim Breitner wrote:
[...]
> now I also get SPJ’s output. I did not get it until I ran "git submodule
> update && make", and the reason might be that now, two versions of
> transformers are registered in the inplace data base
>
> $ ./inplace/bin/ghc-pkg list|gr
On 2014-05-08 at 14:03:22 +0200, Simon Peyton Jones wrote:
> Dear ghc-devs
> Cabal can't open a TCP connection from my Linux box. It used to work fine.
> Here's what it says:
[...]
> proxy uri host: , port:
> Creating new connection to
> cabal: openTCPConnection: host lookup failure for ""
my
On 2014-05-03 at 08:31:47 +0200, Mateusz Kowalczyk wrote:
[...]
> I just tried to compile a snapshot involving this commit and got a
> compile failure:
>
> http://lpaste.net/103540
>
> I was compiling with GHC 7.8.2 on a 32-bit machine.
The nightly 32bit GHC HEAD PPA build failed as well, see
On 2014-04-29 at 12:27:38 +0200, Simon Marlow wrote:
[...]
>>> I think that's fine. As Simon points out, we already have lagging
>>> repo functionality in the form of the submodule links, so the repo on
>>> git.haskell.org can be a pure mirror.
>>
>> Just so I get this right, does "pure mirror"
Hello Simon,
On 2014-04-28 at 11:28:35 +0200, Simon Marlow wrote:
[...]
>> However, we can configure the lagged mirror such that we'd automatically
>> mirror github's 'master' branch into our lagged mirror (we'd still be
>> free to create local wip/* or ghc-7.10 branches at git.haskell.org if
>>
On 2014-04-28 at 10:40:15 +0200, Simon Peyton Jones wrote:
> In general I'd like to make the infrastructure reflect the story of
> who is managing these packages. Moreover, those who are maintaining a
> package, in this case the core-libraries committee, should have the
> final word on where their
Hello Simon,
On 2014-04-28 at 10:16:39 +0200, Simon Marlow wrote:
> So let me check that I'm understanding correctly. Right now the
> source of truth for these repos is under git.haskell.org/ghc, and
> you're proposing that we move the source of truth to github. In
> addition we would still need
Hi GHC devs,
In accordance with Edward and Austin, I want to move the primary home of
the non-GHC specific core-library packages to the
http://github.com/haskell/ organization.
Specifically, I plan to move the following package Git repositories to
the github.com/haskell organization:
- array
-
On 2014-04-22 at 14:42:46 +0200, Austin Seipp wrote:
[...]
> - I've been looking into our CI setup for GHC, and evaluating things.
> Right now though, I am directly working on getting Windows build bots
> set up on Gabor's infrastructure. He gave me the credentials, and
> hopefully this should n
Hello Richard,
On 2014-04-24 at 15:04:55 +0200, Richard Eisenberg wrote:
> That map seems to store the set of variables during printing TH, for
> the purposes of disambiguating identifiers with the same name but
> different uniques. If blatting out a whole lot of program text, I
> could imagine th
On 2014-04-24 at 12:38:40 +0200, Simon Peyton Jones wrote:
> OK. So are you saying that you can't reliably change to a different
> branch in an existing tree, but rather must freshly clone from the
> source each time you want to check out a different branch?
>
> That seems a bit extreme. I though
Hello *,
In order to address
https://github.com/haskell/cabal/issues/1811
I've prepared a commit for review at
https://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/drop-containers-dep-from-th
However, I'm wondering if we really need Data.Map, or if would be
equally ok to simply use
On 2014-04-22 at 09:49:22 +0200, Karel Gardas wrote:
> I hope you are the right person to ask, but it looks like after
> folding base/template-haskell/ghc-prim/integer-gmp/ etc. libraries to
> ghc tree the build's checking clean step reports a lot of non-deleted
> files. This makes our builder logs
On 2014-04-13 at 09:58:50 +0200, Herbert Valerio Riedel wrote:
[...]
> - base
> - ghc-prim
> - integer-gmp
> - integer-simple
> - template-haskell
[...]
> If no objections are raised, I'm planning to implement this change
> next weekend (April 19th/20th).
As there
On 2014-04-19 at 14:08:19 +0200, Daniel Fischer wrote:
[...]
>> Klone nach 'libraries/xhtml'...
>> Fertig.
>> Unterprojekt-Pfad: 'libraries/xhtml':
>> 'fb9e0bbb69e15873682a9f25d39652099a3ccac1' ausgecheckt fatal: Projektarchiv
>> '/home/dafis/GHC/./haddock.git' existiert nicht. Klonen von
>> '/ho
On 2014-04-18 at 12:13:14 +0200, Karel Gardas wrote:
> Folks,
>
> last two/three builds on Solaris builder fails due to a reason that
> someone added (probably) stripping of installed libraries. My bet is
> on 8992d5269804b727fb77249511e89df678526907 -- hence ccing you
> Herbert, but I'm not sure..
On 2014-04-15 at 05:38:54 +0200, Kazu Yamamoto (山本和彦) wrote:
> Hi Herbert,
>
>> After a short conversion with Austin and Edward it appears that the
>> sensible course of action with respect towards moving to a proper Git
>> submodule set-up is to fold-in the 5 Git repos listed below (which btw
>> a
On 2014-04-14 at 11:13:02 +0200, Simon Peyton Jones wrote:
[...]
> #both modified: utils/haddock
> The modified files are right. It's the "both modified utils/haddock" that is
> messing me up.
> I'm not modifying haddock! I just want to say "take the master haddock", but
> I don't k
Hi,
(probably) fixed by
http://git.haskell.org/ghc.git/commitdiff/b4a820f97e48199a92f5ce7216731500f9a841c9
On 2014-04-14 at 09:15:42 +0200, Páli Gábor János wrote:
[...]
> utils/haddock/src/Haddock/Interface/Create.hs:367:44:
> Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Nam
201 - 300 of 426 matches
Mail list logo
