Hi,
Some guys reported to me that ghc-mod uses about 1G bytes on Mac and I
can reproduce this. I tried to understand why ghc-mod uses such huge
memory.
I found that GHC API 7.8.x uses much more memory than GHC API 7.6.x.
Attached two files demonstrate this:
- A.hs -- Simple program
Dear GHC devs
Is it possible to stop spam on GHC's Trac?
Simon
-Original Message-
From: ghc-tickets [mailto:ghc-tickets-boun...@haskell.org] On Behalf Of GHC
Sent: 14 July 2014 04:24
Cc: ghc-tick...@haskell.org
Subject: [GHC] #9310: This Cleanse Ultima is very beneficial to regulate a
On 07/14/14 09:00 AM, Kazu Yamamoto (山本和彦) wrote:
Mac (64bit) Linux (64bit)
GHC 7.6.3: 20MB4MB
GHC 7.8.3:106MB 13MB
On Solaris 11 i386 (32bit binary) I see:
GHC 7.8.2: 91MB (size), 81MB (RSS)
GHC 7.6.3 53MB (size), 44MB (RSS)
Cheers,
Karel
Would you like to create a Trac ticket?
Is anyone able to investigate?
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Kazu
| Yamamoto
| Sent: 14 July 2014 08:00
| To: ghc-devs@haskell.org
| Subject: Huge space leak of GHC API 7.8.x?
|
|
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)
Hi,
Am Montag, den 14.07.2014, 09:43 +0200 schrieb Herbert Valerio Riedel:
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
| I can do the former, but the latter needs to be done by a member of the
| “ghc” on GitHub. I can do the latter (and keep managing the travis
| instance) if someone adds me to the organization...
Johachim, you contribute a lot, thank you. You should be a member of the
group!
Who decides
| I started monitoring perfomance on a per-commit base. These seem to
| be
| off for a while now. Adjusting them, and from now I hope I can keep
| closer tabs on them.
Thank you. That's most helpful. One of the reasons that perf tests get worse
is that each time the limit is
Hi,
Am Montag, den 14.07.2014, 11:13 + schrieb Simon Peyton Jones:
I'ts important to monitor the actual bump, rather than the first time
the limit is broken. (They aren't the same, of course.)
Quite right.
I am in the process of setting up per-commit monitoring of _nofib_
results, and I
Hi Karel,
usually I do not build HEAD. My attempt starting to do so failed as follows:
git clone git://git.haskell.org/ghc.git
cd ghc
./sync-all get
autoreconf
./configure
gmake
...
ghc.mk:690: libraries/haskeline/ghc.mk: Datei oder Verzeichnis nicht
gefunden
On 07/14/14 02:53 PM, Christian Maeder wrote:
Hi Karel,
usually I do not build HEAD. My attempt starting to do so failed as
follows:
git clone git://git.haskell.org/ghc.git
cd ghc
./sync-all get
autoreconf
^ I'm not sure, but shouldn't that be `perl boot' ?
./configure
^ if you don't
Hello all,
I've been lax on the status updates, but better late than never. :)
Here are some things that I've been up to.
- 7.8.3 is released! Hooray!
- Phabricator can now build code reviews if you submit them. I sent
an email about this earlier in the week[1] in case you missed it.
The release 7.8.3 bindist for OS X was flawed: It was not build SplitObjs.
That is my fault for not catching it before releasing it. You may demand a
beer from me at ICFP as restitution
I have built a new 7.8.3 bindist for OS X, and tested in 10.9, 10.7, and
10.6(!). It is SplitObjs, and
Cherished GHC devs,
GHC has long since exceeded the modest capacities of GHC HQ, even before Simon
M's move to Facebook. But in fact Simon's move simply made clearer something
that was already true, namely that GHC is *mainly* reliant on the committed
support of its developer community (i.e.
Joachim
In commit 194107ea9333c1d9d61abf307db2da6a699847af you reduced the allocation
of T9203 by half. Butbut I get allocation of 95747304 on my 64 bit machine, so
the test fails.
Any idea why?
Simon
diff --git a/testsuite/tests/perf/should_run/all.T
b/testsuite/tests/perf/should_run/all.T
Hi all,
Sometimes, the progress on a particular issue is tracked both on Trac and on
Phab. What posts should go where? I know Austin is trying to get Trac to be
notified when a relevant post happens on Phab -- great. But, if I have a
comment, where should I put it?
Here is my proposed answer:
Hi,
Am Montag, den 14.07.2014, 16:43 + schrieb Simon Peyton Jones:
In commit 194107ea9333c1d9d61abf307db2da6a699847af you reduced the
allocation of T9203 by half. Butbut I get allocation of 95747304 on
my 64 bit machine, so the test fails.
no, and and I wish I had. See (and continue on)
| Here is my proposed answer: The Phab reviews are a good place for code-
| specific commentary/feedback but Trac is better for design issues. A rule
| of thumb might be to pretend that Phab comments are all forgotten in a
| month or two, whereas Trac comments are expected to be around in 5 years.
PS: and if we agree this convention can we document it in our Working
Conventions pages?
S
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon
| Peyton Jones
| Sent: 14 July 2014 20:25
| To: Richard Eisenberg; ghc-devs@haskell.org
| Subject:
On Mon, Jul 14, 2014 at 1:41 PM, Richard Eisenberg e...@cis.upenn.edu wrote:
Hi all,
Sometimes, the progress on a particular issue is tracked both on Trac and on
Phab. What posts should go where? I know Austin is trying to get Trac to be
notified when a relevant post happens on Phab --
| Look at the top - there is a link to 'Phab:D69', which is the
| differential revision hyperlinked properly.
|
| If you use this syntax in Trac now, it will automatically hyperlink
| revisions. Perhaps in the future we can shorten it to just 'D69' for
| example. But this syntax works now to
| One thing, how about an addition to the release notes in the
| -dynamic-too section saying By the way, this doesn't actually work,
| see https://ghc.haskell.org/trac/ghc/ticket/8736.;
Not a bad idea. Austin can we conveniently do that retrospectively?
I spent a bit of time over the weekend trying to figure out how to force
the RTS to collect GC statistics, but was unable to do so.
I'm currently working on enriching criterion's ability to gather data,
among which I'd like to see GC statistics. If I try to obtain GC stats
using criterion when
Any suggestions? I'm still stuck on this, and don't really know what to try
next.
Andrew
On Thu, Jul 10, 2014 at 9:36 PM, Andrew Gibiansky
andrew.gibian...@gmail.com wrote:
Hello,
I am trying to create my first patch, for #9294, where I want to export
some extra things from Parser along
if you wanna resuse the same source tree, the heavy hammer for doing a
rebuild is
make maintainer-clean ; make
maintainer-clean wipes alll build artifacts so its a clean tree, so
everything will be built from scratch
there might be a better way, but that sledgehammer should work
On Mon, Jul
wooops, would need to be
make maintainer-clean ; perl boot ; ./configure ; make
On Mon, Jul 14, 2014 at 11:07 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
if you wanna resuse the same source tree, the heavy hammer for doing a
rebuild is
make maintainer-clean ; make
26 matches
Mail list logo
