Re: DNS entry for git.haskell.org active now!

On 2013-08-20 at 09:48:48 +0200, Simon Peyton-Jones wrote: > | However, in order to facilitate future migrations, git.haskell.org > | should be used, as then we could relocate git.haskell.org to a different > | IP without needing to update the URLs in all documents again. > > Why? If we only had g

Re: Disallow pushing of new trailing whitespace

On 2013-08-20 at 13:21:02 +0200, Geoffrey Mainland wrote: > How about a third hook that disallows commits that include > whitespace-only changes unless *all* changes are whitespace-only? ;) The other two validations were about preserving an invariant ("file has no tabs" & "file has no trailing whi

./sync-all get & git submodule URL dissonance (was: It's one of those days...)

On 2013-08-22 at 15:35:29 +0200, Ben Lippmeier wrote: [...] > I was confused because the ./sync-all script gets most of the repos > with git:// style URLs, but then switches to http:// style URLs for > sub modules. well, that's because the 'sync-all' script is not clever enough to rewrite the ur

(in-place) mutable unboxable Ints (was: [GHC] #8158: Replace IO manager's IntMap with a mutable hash table)

Hello Simon, On 2013-08-24 at 08:54:20 +0200, GHC wrote: [...] > Comment (by simonmar): > > @bos: GHC has a `FastMutInt` type for this purpose, which is a 1-element > mutable unboxed array. I'd be interested to know whether performance > differs between this and `ForeignPtr`. > > source:ghc/c

Re: [commit: ghc] master: Update email addresses (cbe3dba)

Hello Gabor, On 2013-08-22 at 22:51:31 +0200, g...@git.haskell.org wrote: > Link : > http://ghc.haskell.org/trac/ghc/changeset/cbe3dba89c085f7556fe32126381dac68d93dd8b/ghc > commit cbe3dba89c085f7556fe32126381dac68d93dd8b > Author: Gabor Greif > Date: Mon Aug 19 11:31:15 2013 +0200 > >

Re: Changes to primops break libraries (was Re: 7.8 Feature window)

On 2013-08-26 at 10:56:15 +0200, Gregory Collins wrote: > On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow wrote: >> On 25/08/13 20:16, Jan Stolarek wrote: >>> We really want people to use the new primops, not the wrappers >>> We do? Could you justify why we want to people to use primops? >>> >>

Current state of ghc boot lib versions vs. hackage

I've compared what versions current GHC HEAD uses w/ vs. what's currently available on Hackage (see below); So currently, the following packages have newer versions available on hackage than are used in GHC HEAD: - binary - containers - primitive - time - vector In order to clarify a point

Re: FW: [GHC] #8186: Parallel comprehensions not allowed in Template Haskell quotes

Hello Simon, On 2013-08-28 at 10:14:36 +0200, Simon Peyton-Jones wrote: > With Gitolite, the Trac tickets now get messages like this: [...] > I liked the old version: > the author is more explicit > the modified files are listed > if the patch is small you see it all > > Might it be

New official language extension tokens for GHC 7.8.1

Hello GHC Devs, Which of the language extensions listed in `expectedGhcOnlyExtensions` in http://ghc.haskell.org/trac/ghc/browser/testsuite/tests/driver/T4437.hs#L33 are deemed ready for public consumption in GHC 7.8.1, and can be registered with upstream Cabal now (maybe even for the upcoming

Re: New official language extension tokens for GHC 7.8.1

On 2013-09-03 at 23:15:43 +0200, Ian Lynagh wrote: [...] > I'm afraid I can't even remember what RelaxedLayout does OTTOMH. fwiw, here's the commit that introduced it: http://git.haskell.org/?p=ghc.git;a=commitdiff;h=9a82b1ffa35fa4c3927c66a1037a37d436cf6aac ...and moreover, you disabled it by

Re: delete remote branch

Hello Nicolas, On 2013-09-08 at 09:41:04 +0200, Nicolas Frisby wrote: > I just merged in my -fdicts-strict work, so I was deleting the old branch… > but it's rejected for some reason. > > $ git push origin --delete dicts-strict > remote: performing tab-check... > remote: + refs/heads/dicts-strict

Bit-rotting(?) HUGS-specific code in GHC boot libraries

Hello GHC devs, ...as the topic came up in #ghc, what's the current rationale for keeping HUGS-specific code sprinkled throughout GHC boot libraries? I quick tally in GHC's source tree via find -type f -iname '*.*hs' | xargs grep '#if.*HUGS' | cut -f1-3 -d/ | uniq -c results in 1 ./lib

Re: delete remote branch

Hello Geoffrey, On 2013-09-11 at 22:29:04 +0200, Geoffrey Mainland wrote: [...] > Is there any chance we could get the wip namespace up and running soon? Sure, I've enabled it right now (and we can change the "wip/" branch-prefix lateron should we come up with a better naming); there's only the

Re: Bit-rotting(?) HUGS-specific code in GHC boot libraries

Hi, On 2013-09-15 at 09:06:13 +0200, Austin Seipp wrote: > I'm voting we delete it. In fact: I say if nobody pipes up and is > *committed* to maintaining it, we delete it, oh, two weeks. That's > standard library-proposal timeframe. (And I do mean maintenance - not > "drop barely enough work to ge

Re: I've moved the primitive package to github

Hello Jan, On 2013-09-24 at 20:47:31 +0200, Jan Stolarek wrote: >> Your patches are based on an outdated version of the library. > That's really surprising - I based them on code available at > http://code.haskell.org/primitive, > which I believe was version 0.5.0.1. Was there anything newer?

Re: I've moved the primitive package to github

On 2013-09-25 at 05:50:23 +0200, Bryan O'Sullivan wrote: > On Tue, Sep 24, 2013 at 6:17 PM, Herbert Valerio Riedel wrote: > >> However, I've tried integrating the new vector/primitive versions >> released into the GHC build (after patching up the DPH libs), b

Re: I've moved the primitive package to github

On 2013-09-25 at 02:40:51 +0200, Geoffrey Mainland wrote: [...] >> However, I've tried integrating the new vector/primitive versions >> released into the GHC build (after patching up the DPH libs), but I get >> Core lint errors: >> >> http://lpaste.net/93354 >> >> any idea what's going on here?

Re: I've moved the primitive package to github

Hello Jan, On 2013-09-25 at 08:26:15 +0200, Jan Stolarek wrote: >> However, I've tried integrating the new vector/primitive versions >> released into the GHC build (after patching up the DPH libs), but I get >> Core lint errors: >> >> http://lpaste.net/93354 >> >> any idea what's going on here?

Re: I've moved the primitive package to github

Fyi, I've been able to reproduce this failure on GHC 7.6.3 as well, and filed a ticket at http://ghc.haskell.org/trac/ghc/ticket/8355 On 2013-09-25 at 09:24:22 +0200, Herbert Valerio Riedel wrote: > Hello Jan, > > On 2013-09-25 at 08:26:15 +0200, Jan Stolarek wrote: >>&

Re: newSession

On 2013-09-25 at 04:52:33 +0200, Kazu Yamamoto (山本和彦) wrote: > It seems to me that "newSession" does not exist. But it is used in > comments and error messages. fwiw, it seems to have been removed back in 2008: http://git.haskell.org/ghc.git/commitdiff/1c7d0ac0a433f85effeb5e9cfb6b303c26b201d1

Re: HEAD vs Hackage status report

On 2013-09-30 at 08:26:10 +0200, Bryan O'Sullivan wrote: [...] > Most of the breakage could be fixed by loosening the dependencies on the > template-haskell and primitive packages, and here are the rest. Btw/fyi, as one of the new killer features of Hackage 2, incorrect build-deps were supposed

Re: New space leak?

On 2013-10-01 at 12:19:16 +0200, Simon Marlow wrote: > That would help, but since this regression is quite recent I'm hoping > that someone will know what caused it. Did anyone notice when these > failures first appeared? It is certainly not the patches I'm working > on, because I see the same fa

ghc.haskell.org updated to Trac 1.0.1

Hello *, The Trac instances at ghc.haskell.org have been upgraded to the current stable Trac 1.0.1 release in order to alleviate some technical issues with the aging Trac 0.12.x line. Ideally, you shouldn't notice any regressions; however, as a side-effect Trac 1.0.x has a slightly different look

Re: [commit: packages/dph] master: Update build-deps to allow `array-0.5.0.0` (8ee1d9f)

On 2013-10-12 at 00:07:44 +0200, Gabor Greif wrote: > Herbert, > > I guess you have excluded 0.4.x with these changes. Do you have 0.5.x > already installed? Yes, that excludes 0.4.*, as I assumed that the DPH libs need only to be built with the GHC source tree's array package (which has been bump

Re: GHC HEAD vs Hackage, panic-free edition

Hello Bryan, On 2013-10-11 at 20:27:08 +0200, Bryan O'Sullivan wrote: [...] > For packages that are listed in blue, the versions that are breaking are > the latest available. I've CCed the authors of said packages on this email. > Folks, please fix your stuff! btw, is there somewhere some wiki-

Re: ghc-compete, a repository of fingerprints, and continuous integration

Hello Simon! On 2013-10-11 at 12:59:07 +0200, Simon Marlow wrote: [...] > This is great. With a bit of extra tool support for this we could > actually do without submodules and go back to individual > repos. Checking out a GHC revision in the past could consist of > querying your ghc-complete r

Re: [commit: packages/unix] master: Fix assumption that RLIM_INFINITY is a simple number (b092e35)

Hello Bryan, Thanks for catching this! (see also comment below) [...] > commit b092e35f4c99bfab12247e93c7fa478de638276a > Author: Bryan O'Sullivan > Date: Sat Oct 12 16:45:50 2013 -0700 > > Fix assumption that RLIM_INFINITY is a simple number > > On MacOS X, it is defined as "(((

Re: [commit: packages/unix] master: Fix assumption that RLIM_INFINITY is a simple number (b092e35)

On 2013-10-14 at 06:07:01 +0200, Bryan O'Sullivan wrote: [...] > You'll want to take a look at what hsc2hs actually does here to really > understand :-) > > In short, a constant C-level expression is fine if used in a #const > construct, regardless of it containing embedded casts and whatnot. th

Re: ghc-compete, a repository of fingerprints, and continuous integration

Hello Simon, On 2013-10-15 at 14:45:05 +0200, Simon Marlow wrote: [...] > If we can get the tooling right I would probably have no objections to > submodules. Right now it's a bit of a pain though. > > - extra steps in the workflow for modifying a library (git checkout >master, etc.) Ok,

Re: [commit: packages/stm] master: Refactor & update `stm.cabal` to `cabal-version>=1.10` (aa4774b)

...for those interested in following a forked discussion of this thread that has migrated to cabal-de...@haskell.org: http://www.haskell.org/pipermail/cabal-devel/2013-October/009589.html Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org h

Significant size increase in GHC HEAD's static library sizes

Hello * While generating .deb packages of various GHC 7.x releases[1] I noticed a peculiar jump in the resulting binary .deb package for GHC HEAD (about +50% wrt to GHC 7.6.3); at first I thought this was mostly due to having enabled shared libaries for that particular package, but then I compared

Re: pull failing due to deleted .buildinfo files

On 2013-10-25 at 11:54:29 +0200, Simon Marlow wrote: > I just tried to pull into my tree, and encountered several failures of > this kind: > > == libraries/process: running git pull --rebase > Cannot pull with rebase: You have unstaged changes. > Please commit or stash them. > > But I have made no

Re: pull failing due to deleted .buildinfo files

On 2013-10-25 at 11:54:29 +0200, Simon Marlow wrote: [...] > # Changes not staged for commit: > # deleted:process.buildinfo > > I know how to revert this and keep going, but it seems that the build > shouldn't be deleting files in the repo. Anyone know anything about > this? The probl

old-time.git/tests/time004.hs is DST-sensitive :-/

Hi *, if anyone wonders, why TEST=time004 suddenly fails: it's sensitive to DST (and depends on your system's TZ-config): http://git.haskell.org/packages/old-time.git/blob/HEAD:/tests/time004.hs For me, the comparison this unit-test checks now suddenly fails, because the DST-switch occurs on d

Current link-destination Haddock warnings in base

Hello *, ...currently, when generating Haddock for `base` I see the warnings below; shall those warnings remain for GHC 7.8.1, or do we want to export (at least some of) the missing link destinations to reduce the amount of Haddock warnings? , | Warning: Data.Type.Coercion: could not find lin

Re: Another CPP gotcha for the manual

Hello Malcolm, On 2013-11-04 at 10:28:27 +0100, Malcolm Wallace wrote: > Of course, cpphs solved this problem nearly a decade ago. Btw, what has been the reason it hasn't been adopted as bundled `cpp` replacement in the GHC distribution in the past? (if it remains a separate executable, its GPL l

Re: [commit: packages/integer-gmp] master: Clean-up Cmm of import/export primitives (dfd65a2)

On 2013-11-05 at 22:08:11 +0100, Gabor Greif wrote: > I suppose the integer-simple library also needs the treatment. > Many embedded platforms won't have GMP. > Should we just provide 'error "unimplemented"' stubs? Well, I extended the precedent set by http://www.haskell.org/ghc/docs/latest/ht

Re: Unicode quotes

On 2013-09-04 at 09:24:38 +0200, Kazu Yamamoto (山本和彦) wrote: > GHCi of GHC 7.7 use Unicode quote marks instead of ASCII quote marks. > Why do you guys decide this behavior change? I'm just curious. seems to be due to http://ghc.haskell.org/trac/ghc/ticket/2507 _

Re: Windows validate failure

On 2013-09-22 at 15:59:01 +0200, Simon Peyton-Jones wrote: > My latest Windows validate fell over as below, with some kind of > Python failure (ie not just a failing test). It worked fine couple of > days ago. Does anyone have any ideas of what might be going on? Seems to be caused by this:

Re: Cabal-1.18.1.1 released

Hello Johan, On 2013-10-16 at 01:00:17 +0200, Johan Tibell wrote: > I've released Cabal-1.18.1.1, which requires the fixes needed for the GHC > 7.8 release. Please update the submodule to point to the Cabal-v1.18.1.1 > tag. Done: http://git.haskell.org/ghc.git/commitdiff/0a80baa559be5d107f9

Re: Trac formatting

On 2013-11-13 at 11:36:13 +0100, Simon Marlow wrote: > On 12/11/13 15:53, Joachim Breitner wrote: > >> Am Dienstag, den 12.11.2013, 15:24 + schrieb Simon Peyton-Jones: >>> When Trac formats commit messages it is doing a terrible job. See for >>> example: https://ghc.haskell.org/trac/ghc/ticket

Re: Trac formatting

On 2013-11-14 at 13:07:00 +0100, Simon Marlow wrote: [...] > Obviously this is all just MHO, if everyone else wants markup in > commit messages then I won't complain. btw, I'm keeping my eyes open to see how easy it'd be to support specific renderer for commit messages, with a simple/reasonable

Re: clang/wrapper cannot build GHC head with integer-gmp on Mavericks

On 2013-11-20 at 14:40:27 +0100, Kazu Yamamoto (山本和彦) wrote: [...] > If we type "CC=clang ./configure", it works. The problem is how to > specify "CC=clang" to configure of libgmp when we build GHC head. If > we modified "libraries/integer-gmp/gmp/ghc.mk" manually, we can build > GHC head. But I

Re: RTS warnings

On 2013-11-27 at 23:15:29 +0100, Gabor Greif wrote: [...] > PS: there is also this low-hanging fruit: > > libraries/containers/Data/IntSet/Base.hs:1196:17: Warning: > In the use of 'bitSize' (imported from Data.Bits): > Deprecated: "Use bitSizeMaybe or finiteBitSize instead" fyi, https:

Re: build errors

On 2013-11-29 at 03:30:56 +0100, Kazu Yamamoto (山本和彦) wrote: >> I cannot build GHC head on Linux and Mac (Mavericks) today: >> >> compiler/typecheck/TcEvidence.lhs:152:16: >> Not in scope: data constructor `ASSERT2' > > The attached patches are necessary to build GHC head on Mavericks. thanks

Re: __builtin___clear_cache

On 2013-11-29 at 03:37:43 +0100, Kazu Yamamoto (山本和彦) wrote: > 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced > __builtin___clear_cache. I think this is GCC specific. > So, Storage.c cannot be compiled with clang: > > > rts/sm/Storage.c:1294:3: > error: use of unknown builtin '__buil

Re: Repository Reorganization Question

On 2013-12-04 at 22:24:40 +0100, Austin Seipp wrote: > So, the question is: should we go ahead and pull the trigger on some > of these perhaps? Herbert collected some numbers on the git > repositories and outlined all the basic details here: > > https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorgani

Re: Repository Reorganization Question

On 2013-12-05 at 11:17:01 +0100, Herbert Valerio Riedel wrote: [...] > Fyi, I've drafted how the change would look like in the new ghc.git > branch 'wip/T8545' so we can test/evaluate the effects/fallout before > peforming this operation on 'master'. > >

Re: Repository Reorganization Question

Hello Joachim, On 2013-12-05 at 12:56:55 +0100, Joachim Breitner wrote: > Am Donnerstag, den 05.12.2013, 12:15 +0100 schrieb Herbert Valerio > Riedel: >> PS: I didn't merge in testsuite's Git history as that would bloat >> ghc.git quite a bit; > > would that

Re: Repository Reorganization Question

On 2013-12-05 at 12:31:40 +0100, Simon Peyton-Jones wrote: > What (if anything) do we need to do when updating existing local repos. Will > everything be ok if I just do >sync-all pull ...assuming there's no important uncommitted data left in testsuite/ (and ideally nowhere else in the sour

Re: Repository Reorganization Question

On 2013-12-05 at 15:17:53 +0100, Ian Lynagh wrote: > On Thu, Dec 05, 2013 at 03:03:42PM +0100, Herbert Valerio Riedel wrote: >> >> However, if the testsuite/ was already checked out before the 'sync-all >> pull', the 'testsuite/.git' folder won't be r

Re: Repository Reorganization Question

On 2013-12-05 at 14:32:10 +0100, Herbert Valerio Riedel wrote: [...] > whereas, when I create a new git repo containing only the HEAD commit > from testsuite.git, the resulting single packfile: > > 204K Dec 5 14:19 > .git/objects/pack/pack-27355d714321978fd34c21ce341a7b55f4167

Re: Repository Reorganization Question

On 2013-12-06 at 13:01:41 +0100, Johan Tibell wrote: > When we merge in the testsuite repo, can we still keep the old commit IDs? > They're referenced from all over the place. ...if we want to preserve the old testsuite's commit-ids, then we'll have to live with carrying around those superflous la

Re: Repository Reorganization Question

On 2013-12-06 at 13:50:55 +0100, Johan Tibell wrote: > Whichever way to go, we should write down the options and consequences and > communicating them widely enough so no core devs get surprised. > > Commit IDs for the test suite are referenced in e.g. various Trac issues, > on mailing lists (altho

Re: Repository Reorganization Question

On 2013-12-09 at 09:18:09 +0100, Simon Marlow wrote: [...] >> ...as I hinted at in an earlier post, the old commit-ids will still >> allow to find the original commit; for isntance, there's already the >> find-commit-by-sha1 service at >> >>http://git.haskell.org/.findhash/ >> >> which search

Re: Repository Reorganization Question

On 2013-12-09 at 09:34:23 +0100, Joachim Breitner wrote: > Am Montag, den 09.12.2013, 09:24 +0100 schrieb Herbert Valerio Riedel: >> What kind of links are you referring to btw? I don't see any clickable >> GHC SHA1 ids these days anymore... :-) > > well, people do

Please help complete `.mailmap`

Hello *, I've been trying to (re)construct a .mailmap file[1] in ghc.git which allows `git shortlog` and `git log --use-mailmap` (and possibly other tools/commands) to fixup bogus author-ids when displaying the Git history, in the hopes to provide a more complete history of GHC and all contributor

Re: Repository Reorganization Question

On 2013-12-09 at 13:31:15 +0100, Austin Seipp wrote: > It seems that while most people are in favor of migrating and > preserving the history there are a few sticky bits concerning some of > the minor details. So I think the discussion should continue, but we > clearly shouldn't pull the trigger qu

Re: Building Haddock in GHC source tree (Re: Preparing for a review of pattern synonyms)

On 2013-12-10 at 15:24:33 +0100, Dr. ERDI Gergo wrote: > On Tue, 10 Dec 2013, Dr. ERDI Gergo wrote: > >> OK, I'll add pattern synonym support for Haddock. > > Ummm..., so how do I build the version of Haddock included in the GHC > source tree under utils? I tried just > $ cd utils/haddock > $ make

Re: Repository Reorganization Question

Hi Ben, On 2013-12-10 at 17:53:23 +0100, Ben Gamari wrote: > If the old commit IDs are really needed, one would think it wouldn't be > too hard to write them into the commit message while rewriting > history. That way you could at least `git log --grep` IIRC. Good idea, that's quite easy actually

Re: Idea for improving communication between devs and potential devs

On 2014-01-03 at 21:57:18 +0100, Howard B. Golden wrote: > In addition, I'd like to start some sort of "what's new" that boils > down the GHC Dev mailing list discussion as LWN does for the Linux > kernel mailing list. maybe https://ghc.haskell.org/trac/ghc/blog could be revived by that...? _

High-level Cmm code and stack allocation

Hello, According to Note [Syntax of .cmm files], | There are two ways to write .cmm code: | | (1) High-level Cmm code delegates the stack handling to GHC, and | never explicitly mentions Sp or registers. | | (2) Low-level Cmm manages the stack itself, and must know about | calling c

Re: High-level Cmm code and stack allocation

On 2014-01-05 at 00:26:52 +0100, Herbert Valerio Riedel wrote: [...] > So is this valid high-level Cmm code? What's the proper way to allocate > Stack (and/or Heap) memory from high-level Cmm code? PS: ...are function calls supposed to work as advertised in https://github.com/g

Re: High-level Cmm code and stack allocation

On 2014-01-05 at 01:15:53 +0100, Carter Schonwald wrote: > hey Herbert, > I generally start with looking at the primops.cmm file for examples > https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L572-L588 stg_decodeFloatzuIntzh ( F_ arg ) { W_ p, mp_tmp1, W_ mp_tmp_w;

Re: High-level Cmm code and stack allocation

On 2014-01-05 at 01:32:07 +0100, Carter Schonwald wrote: > i'm inclined to assume that its a parser error. > instead of (v)= call fun(args...argn);, did you try v = call fun(args1...n) > ; ? I've looked more closely at the parser, and the relevant productions... | 'call' expr '(' exprs0 ')' '

Re: [PATCH] platformFromTriple: fix to recognize Solaris triple (i386-pc-solaris2.11)

Hello Karel, Please submit this fix at the upstream Cabal project at https://github.com/haskell/cabal/issues When it's merged upstream we can sync up GHC's in-tree copy of the Cabal library to Cabal upstream. Thanks, hvr On 2014-01-05 at 18:14:08 +0100, Karel Gardas wrote: > --- > Cabal/Dis

Re: High-level Cmm code and stack allocation

Hello Simon, On 2014-01-07 at 17:04:52 +0100, Simon Marlow wrote: [...] > Yes, this is technically wrong but luckily works. ...but only as long as the code-generator doesn't try to push something on the stack, like e.g. when performing native 'call's which need to push the return-location on

Folding ghc/testsuite repos *now*, 2nd attempt (was: Repository Reorganization Question)

Hello All, It seems to me, there were no major obstacles left unaddressed in the previous discussion[1] (see summary below) to merging testsuite.git into ghc.git. So here's one last attempt to get testsuite.git folded into ghc.git before Austin branches off 7.8 Please speak up *now*, if you hav

HEADS-UP: testsuite has been folded into ghc; back up your old testsuite/ folder!

Hello *, It's finally done; effective immediately, the testsuite/ folder is now tracked as part of ghc.git (for the master branch) *IMPORTANT* If there's any chance you have something importing lying around in your testsuite/ please move it out of the way preemptively (e.g. with 'mv testsuite/ te

Re: testsuite change

Hello Simon, On 2014-01-13 at 13:08:02 +0100, Simon Peyton Jones wrote: > I did 'git pull' in my source tree and got the error below. What do > I do now? the easist is to just move the testsuite folder out the way; e.g. mv testsuite/ testsuite-old/ ___

Re: testsuite change

27;git log' and other common Git commands to find out if there's something worth saving over from the old standalone testsuite.git (Git commands will use the first found .git/ folder while traversing upwards towards the filesystem root) HTH, hvr > > > | -Original Mess

Re: [commit: packages/integer-gmp] master: Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type (7bdcadd)

427f0685493f3a2e5c5fa/integer-gmp >> >>> --- >> >> commit 7bdcadda7e884edffb1427f0685493f3a2e5c5fa >> Author: Herbert Valerio Riedel >> Date: Thu Jan 9 00:19:31 2014 +0100 >> >>

Re: [PATCH] platformFromTriple: fix to recognize Solaris triple (i386-pc-solaris2.11)

Hello Karel, On 2014-01-13 at 18:13:55 +0100, Karel Gardas wrote: > Hello Herbert, > > the fix in a little bit extended version is already up-stream: > https://github.com/haskell/cabal/commit/98a3feb23364897779dd665758949555a84dc5b8 well, it's a first step that's in the master branch, but GHC HEA

Re: ghci verbosity

Hello Simon, On 2014-01-14 at 14:59:55 +0100, Simon Peyton Jones wrote: > ghc -interactive has just started being more verbose. The > "linking...done" stuff didn't happen before. Does this ring any bells > for anyone? I have not investigated at all so far; hoping someone will > say "oh yes, I kn

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?

On 2014-01-14 at 17:41:48 +0100, Ryan Newton wrote: > I'm wondering if we can do a hackage release of 0.5.3.2? That "splitRoot" > function is in there, and my ability to deploy parallel code that uses > containers depends on people getting it! Are there any other changes since > 0.5.3.1? > > Repl

GHC boot-library package changelogs & release-notes

Hello fellow GHC devs, As some of you might have noticed, I added a changelog.md file to libraries/base: https://github.com/ghc/packages-base/blob/c8634027d4e3315a2276fb1be8168c486419785a/changelog.md (please feel free to fix any typos/omissions/whatever you notice) My hope/motivation is that

Re: GHC boot-library package changelogs & release-notes

Hello Arash, On 2014-01-29 at 18:21:05 +0100, Arash Rouhani wrote: > So who should add to the changelog? If I'm committing a new feature to > the base library, should my commit include a small addition to the > changelog describing my change? If you deem your modification release-note-worthy, the

Re: 7.8 branch is created, HEAD is now open, and a note on merges

Hello Kazu, ..as this is a Cabal issue, this needs to be handled upstream; could you please file an issue at https://github.com/haskell/cabal/issues/new and mention there that we need that to be cherry-picked into the `1.18` branch as well -- as soon as it's in the 1.18 branch, we can update t

Re: [commit: haddock] master: Update tests (18e9417)

On 2014-01-31 at 22:21:09 +0100, Gabor Greif wrote: > Unless I missed something big style, -XTypeHoles has been > renamed to -XTypedHoles and not removed at all. fyi, http://git.haskell.org/ghc.git/commitdiff/235fd88a9a35a6ca1aed70ff71291d7b433e45e4 ___

Re: Cabal release for 7.8

On 2014-02-04 at 06:10:24 +0100, Johan Tibell wrote: > I guess we need one last cabal release for 7.8? Are we ready for that now, > or do you expect any more 7.8 change that will require cabal changes? The RC1 has just started, and I'd rather wait a little more till we're closer to a final release

Re: [commit: ghc] master: Update to primitive-0.5.2.1 (47d725f)

On 2014-02-20 at 08:50:36 +0100, Karel Gardas wrote: > thanks for merging this, but this is somehow not working for me. I see > this patch in ghc repo after ./sync-all pull, but my > libraries/primitive is still on > 5ae8fbb8131ccc934cadd29cc1d17298cfdaef4b commit from November 2013 because it was

Re: 32-bit Linux perf failures

On 2014-02-20 at 16:26:33 +0100, Mateusz Kowalczyk wrote: [...] > While I technically have the push permissions, I'm not a GHC dev. I feel > like it'd be inappropriate to push in such a ‘fix’ myself. I can post a > full validate log if that contains information one would need to update > the numb

Re: OverloadedRecordFields

On 2014-02-25 at 18:42:03 +0100, Adam Gundry wrote: [...] > They are up to date but I'll go over them and tidy them up. Alas, it > doesn't look like Trac supports redirects... actually, it does, but the plugin was just missing; see https://ghc.haskell.org/trac/ghc/wiki/WikiMacros#Description

Re: [commit: packages/base] ghc-7.8: Workaround failed constant-folding for zeroBits (591142f)

On 2014-03-01 at 22:17:18 +0100, Simon Peyton Jones wrote: > Herbert would you like to open a ticket, saying what's wrong and how > to reproduce it? Sure: https://ghc.haskell.org/trac/ghc/ticket/8832 :-) Cheers, hvr ___ ghc-devs mailing list ghc-devs@

Re: git.haskell.org misbehaving?

On 2014-03-04 at 12:57:11 +0100, Simon Peyton Jones wrote: > I'm getting > fatal: read error: Connection reset by peer > > when I try git pull from > git://git.haskell.org/ghc.git > > Works ok if I try > http://git.haskell.org/ghc.git > This happens from both Windows and Lin

Re: Building GHC for performance testing

On 2014-03-06 at 10:50:09 +0100, Johan Tibell wrote: > I'd like to set up a performance build bot for GHC, but before I can do > that I need a script that reliably builds GHC and runs nofib. Do we have > such a script? Here's a strawman proposal for one: > > cabal install happy alex > git c

Re: Building GHC for performance testing

Hi Simon, On 2014-03-08 at 08:18:20 +0100, Simon Marlow wrote: > On 06/03/14 09:50, Johan Tibell wrote: [...] >> * Are there any tweaks to mk/build.mk we can do to >> make the build faster without compromising the results? > > Turn down the stage2 optimisation, and turn off t

HEADS-UP: new server-side validation git hook for submodule updates & call-for-help

Hello *, I've put in place a new server-side validation hook a few days ago, and since nobody seemed to have complained yet, I assume it didn't have any adverse effects so far :-) It will only be triggered when Git submodule references are touched by a commit; you can find some preliminary (but i

Re: HEADS-UP: new server-side validation git hook for submodule updates & call-for-help

Hello Johan, On 2014-03-18 at 19:17:55 +0100, Johan Tibell wrote: > Lets give some example workflows for working with submodules. Here's what I > think a raw (i.e. no sync-all) update to base will look like. Please > correct me if I'm wrong. > > # Step 1: > cd ~/src/ghc/libraries/base > # edit so

HEADS-UP: haddock.git to be turned into submodule soon (was: HEADS-UP: new server-side validation git hook for submodule updates & call-for-help)

Hello * On 2014-03-18 at 11:58:36 +0100, Herbert Valerio Riedel wrote: [...] > The next steps, however, include taking care of the client-side work-flow > for working with a fully "submoduled" ghc.git setup. [...] After having discussed this with the current Haddock maintai

Re: Haddock strings in .hi files

On 2014-03-20 at 11:39:47 +0100, Mateusz Kowalczyk wrote: > [...] the functionality to grab documentation for something can be > provided by Haddock and GHCi then can use that. I think an extra > benefit of this is that we get to decide in Haddock how we present > such documentation: we can have di

Re: [commit: packages/template-haskell] master: Make Pred a type synonym of Type (issue #7021) (57b662c)

On 2014-03-23 at 04:40:14 +0100, Richard Eisenberg wrote: > On Mar 22, 2014, at 9:05 PM, Mateusz Kowalczyk wrote: >> Is there a reason why the Template Haskell version wasn't bumped >> after this change? > > No -- I just didn't think of it. I won't have time in the next few > days to do this (and

Re: HEADS-UP: haddock.git to be turned into submodule soon

On 2014-03-20 at 09:53:32 +0100, Herbert Valerio Riedel wrote: [...] > Details will follow when the conversion of haddock.git is actually > implemented. The conversion has been implemented as of http://git.haskell.org/ghc.git/commitdiff/34b072177b687c8fcc24f87293beae0752e82d32

Re: [commit: ghc] master: Convert haddock into a proper submodule (re #8545) (34b0721)

On 2014-03-23 at 19:53:55 +0100, Simon Peyton Jones wrote: > Do us naïve users need to change our workflow with these submodule > changes? Probably yes... to some extent at least; that's why only haddock.git has been converted for now[1]: to find out empirically what's involved before continuing w

Re: [commit: ghc] master: Convert haddock into a proper submodule (re #8545) (34b0721)

Hello Simon, On 2014-03-24 at 09:37:32 +0100, Simon Peyton Jones wrote: > OK. Some questions. > > · Where is a good place to get a conceptual understanding of > submodules? There were three links at the top of the Wiki page; I assume you want something better than that? > Concerning > https://gh

Re: We need to add role annotations for 7.8

On 2014-03-25 at 09:28:57 +0100, Andreas Abel wrote: [...] > You might wanna pull the break before the release. Fwiw, reverting the new syntax at this point also has an effect on already officially released libraries such as http://hackage.haskell.org/package/containers-0.5.5.1 which started usi

Re: Buildbots

On 2014-04-01 at 12:46:05 +0200, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 01.04.2014, 10:25 + schrieb Simon Peyton Jones: >> Joachim Breitner has set up Travis-CI. (I don't know exactly what >> that is, but it sounds useful.) > > Travis is a free cloud service that runs arbitrary tes

Compiling GHC with Clang

Hello *, I've been trying to compile GHC with Clang instead of GCC on Ubuntu, by configuring the build with CC=/usr/bin/clang ./configure --with-gcc=/usr/bin/clang but then, 'make' runs into , | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm-package-na

Re: Compiling GHC with Clang

On 2014-04-02 at 09:35:31 +0200, Christian Maeder wrote: > I had a similar problem on a Mac (and clang) that I could solve by > updating to the versions of (happy and) alex that you already use. Are > you sure that Lexer.hs was freshly (re-)generated? ...it was freshly generated (by [1] - I forced

Re: Compiling GHC with Clang

On 2014-04-02 at 09:44:03 +0200, Christian Maeder wrote: > Maybe alex needs to be compiled with clang, too? If that's really the case, I have a little bit of a bootstrapping problem: How can I get a Clang-built Alex, on a platform where I only have a GCC-configured GHC available? _

<    1   2   3   4   5   >