On 15/10/14 09:37, Simon Peyton Jones wrote:
I think that would be a fine idea, but it's always hard
- pages change their status (a proposal becomes part of GHC)
- a page may belong in multiple places
- people keep URLs in bookmarks, and they are linked from other pages in Trac
so moving
On 06/11/2014 13:02, Jan Stolarek wrote:
Sometimes we add flags that are for experimentation or development
purposes and not intended for user consumption, and these tend not to be
added to the User's Guide. I suspect many of the flags you mention fall
into this category. I suggest for these
On 07/10/2014 15:52, Simon Peyton Jones wrote:
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.
On 15/09/2014 17:50, Ryan Yates wrote:
I'm starting to get to the bottom of something that has been puzzling me
for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497
[1] introduced the GC write barrier for TVars. Not fully understanding
things and reading the commit message to
was broken too...
On Fri, Oct 17, 2014 at 2:00 AM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
I was working on a fix yesterday but ran out of time. Frankly this
code is a nightmare, every time I touch it it breaks on some
platform - this time I validated on 64 bit Windows
I was working on a fix yesterday but ran out of time. Frankly this code
is a nightmare, every time I touch it it breaks on some platform - this
time I validated on 64 bit Windows but not 32. Aargh indeed.
On 16 Oct 2014 14:32, Austin Seipp aus...@well-typed.com
mailto:aus...@well-typed.com
I believe I've just pushed a fix for this, let me know if you still have
problems.
Cheers,
Simon
On 10/10/2014 13:47, Carter Schonwald wrote:
likewise, 32bit OS X seems to be broken on HEAD too
http://lpaste.net/112412 is the relevant bit
make[5]: Nothing to be done for `all'.
Thanks for letting me know, I'll add a configure test to check for this.
Cheers,
Simon
On 13/10/2014 10:12, Karel Gardas wrote:
Hello Simon,
I'm sorry to disturb you, but your recent patch:
commit 674c631ea111233daa929ef63500d75ba0db8858
Author: Simon Marlow marlo...@gmail.com
Date: Fri
message basically is as
follows:
rts/Linker.c: In function 'mkOc':
rts/Linker.c:2372:6:
error: 'ObjectCode' has no member named 'symbol_extras'
It looks like this patch is the culprit:
5300099ed rts/Linker.c (Simon Marlow 2014-10-01
13:15:05 +0100 2372)oc-symbol_extras
On 27/09/2014 22:04, Gintautas Miliauskas wrote:
8. A broader question: what general approach to ghc on Windows shall we
take? The prebuilt packages currently provided by ghc-tarballs are also
covered by msys2's package manager. Why not offload that pain to msys2
then? The advantage here is
You normally want to do arc diff HEAD^ in my experience. I believe
you get to choose this to be the default when you initialize arc the
first time, and I set it to HEAD^ for my arc. I'm not sure if you can
change the default later, but you can always say arc diff HEAD^.
Cheers,
Simon
On
FastInt = Int#, so newtype doesn't work here.
Cheers,
Simon
On 15/08/2014 14:01, Edward Z. Yang wrote:
The definition dates back to 1996, so it seems plausible that
newtype is the way to go now.
Edward
Excerpts from p.k.f.holzenspies's message of 2014-08-15 11:52:47 +0100:
Dear all,
I'm
that
you can do comparisons).
Another way to test performance is to compile a large module, e.g.
nofib/spectral/simple/Main.hs is a good one.
Cheers,
Simon
Regards,
Philip
From: Simon Marlow marlo...@gmail.com
Sent: 04 September 2014 11:49
To: Edward
On 01/09/2014 12:30, Sven Panne wrote:
2014-09-01 9:26 GMT+02:00 Simon Marlow marlo...@gmail.com:
Hi Sven - you would need to compile the module with -dynamic or -dynamic-too
to have it be picked up by the new dynamically-linked GHCi in 7.8.
Ah, OK... Adding -dynamic makes this work
On 08/08/2014 13:15, Johan Tibell wrote:
We seem to have two ways to get the same piece of information. We can
get the target (?) word size as wORD_SIZE but there's also the
platformWordSize field in the Platform data type, which is held as
targetPlatform in DynFlags. Which one should I use?
Hi Sven - you would need to compile the module with -dynamic or
-dynamic-too to have it be picked up by the new dynamically-linked GHCi
in 7.8.
Cheers,
Simon
On 05/08/2014 12:32, Sven Panne wrote:
Coming a bit late to the party, but I've just realized this when
playing around with the
On 04/08/2014 13:13, Joachim Breitner wrote:
Hi,
Am Montag, den 04.08.2014, 13:08 +0200 schrieb Joachim Breitner:
Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang:
Yes, on my box, this test is now failing (because the stat is too good):
Expectedhaddock.base(normal)
I thought this was what you were already doing :-) Anyway, this is more
or less the setup we had in mind when Haddock was added to the GHC tree.
The only question is which branches are used for GHC and for regular
development, and where they live. As long as that's clear for everyone
(both
On 07/08/2014 16:29, Ömer Sinan Ağacan wrote:
Hi all,
I'm trying to use LDV profiling features of GHC but I'm failing.
Here's what I try:
(I'm using GHC 7.8.2)
* I'm compiling my app with `-prof` and I'm also using `-fprof-auto`
just to be sure.
* I'm running my app using `+RTS -hbdrag,void`
are always 0 or positive. At least,
they were when I introduced them!
SImon
*From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
*Johan Tibell
*Sent:* 07 August 2014 12:21
*To:* Simon Marlow
*Cc:* ghc-devs@haskell.org
*Subject:* Re: Improving the Int/Word story inside GHC
Simon M
On 07/08/2014 12:10, Johan Tibell wrote:
Inside GHC we mostly use Int instead of Word, even when we want to
represent non-negative values, such as sizes of things or indices into
things. This is now causing some grief in
https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation
boundary
On 06/08/2014 21:40, Sergei Trofimovich wrote:
I think I know what happens. According to perf the benchmark spends 34%+
of time in garbage collection ('perf record -- $args'/'perf report'):
27,91% test test [.] evacuate
9,29% test test [.] s9Lz_info
a rather
special case.
Hmmm... the profiling word is the second word of the object, after the
info pointer.
Cheers,
Simon
Simon
| -Original Message-
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 07 August 2014 15:26
| To: Simon Peyton Jones; Johan Tibell
| Cc: ghc-devs
On 07/08/14 16:01, Johan Tibell wrote:
On Thu, Aug 7, 2014 at 4:36 PM, Simon Marlow marlo...@gmail.com wrote:
I think doing the comparison with Integer is the right fix. Relying on Word
being big enough for these things is technically wrong because we might be
cross-compiling from a smaller
Hi Ben,
There has been some confusion here because I accidentally committed a
change to this file that then got reverted. The original fix was #9055,
making it so that on platforms with no registers, globalRegMaybe would
return Nothing (as it should). This wasn't necessary until recently
Sorry for not replying to this earlier. I think after our meeting the
other day we agreed to keep the existing algorithm but document it
better. Here's a stab at describing the spec:
1. compute the set of valid packages, where a package is valid if
- all its dependencies are valid
- it
On 28/07/14 15:37, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/39b5c1cbd8950755de400933cecca7b8deb4ffcd/ghc
---
commit
Hey Bryan,
Sorry for the delay.
On 15/07/14 01:57, Bryan O'Sullivan wrote:
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
On 13/07/14 14:15, Herbert Valerio Riedel wrote:
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
On 22/07/14 08:23, Joachim Breitner wrote:
[Replying to the list, in case it was sent to me in private by accident]
Hi Edward,
Am Montag, den 21.07.2014, 23:25 +0100 schrieb Edward Z.Yang:
Excerpts from Joachim Breitner's message of 2014-07-21 21:06:49 +0100:
maybe a stupid question, but
On 22/07/14 13:17, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of 2014-07-22 12:27:46 +0100:
(Replying to Edward)
It's not clear to me why identical IPID would imply identical package
key. Can't two instances of a package compiled against different
dependencies still have
On 18/07/2014 08:59, Joachim Breitner wrote:
Hi,
Am Freitag, den 18.07.2014, 08:38 +0100 schrieb Simon Marlow:
I might be misremembering, but I believe someone (Ross Paterson?) used
to do this a while ago.
I can't think of any good reasons it *shouldn't* work.
Then, next question
This is great! Can it do alerts, e.g. send a mail to the list when a
metric moves by a certain amount?
Cheers,
Simon
On 16/07/2014 09:02, Joachim Breitner wrote:
Hi,
I guess it’s time to talk about this, especially as Richard just brought
it up again...
I felt that we were seriously
On 19/07/2014 06:00, Kyle Van Berendonck wrote:
I found these:
https://github.com/ghc/ghc/blob/5f3c5384df59717ca8013c5df8d1f65692867825/includes/rts/Constants.h#L194
They go only 0-14, so there's some long chains of branches and stuff in
hot paths that could be cleaned up into single -masked
I might be misremembering, but I believe someone (Ross Paterson?) used
to do this a while ago.
I can't think of any good reasons it *shouldn't* work.
Cheers,
Simon
On 15/07/2014 23:55, Joachim Breitner wrote:
Hi,
I feel sorry for Simon always repeatedly stuck with an unbuildable tree,
and
gcc has -march=native which uses the current CPU's architecture, but I
think it would be a really bad idea to turn that on by default, because
it would mean that we have to be really careful which machine we build
the distributions on.
On my Linux box, gcc -v says it was configured with
Yes, this will cause problems in some modes, namely -debug and -prof
that need to be able to scan the heap linearly. Usually we invoke the
OVERWRITING_CLOSURE() macro which overwrites the original closure with
zero words, but this won't work in your case because you want to keep
the original
On 03/07/2014 09:29, Simon Peyton Jones wrote:
* A *primary* form of consumption is the source code itself. I've found that
Haddock-compliant comments can be rather less readable in source code.
(Eg. CoreSyn.lhs where the #blah# notation coexists uneasily with Note
[blah].)
So I'd be
Austin didn't mention this, so I will: we have a wiki page for style
https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle
It has a pretty clear set of guidelines for imports/exports, for example
(that we don't follow as much as we should).
I'd be in favour of changing .lhs files to
On 06/07/2014 12:25, Christopher Rodrigues wrote:
Investigating #9176 further, GHC does at least three different things
with imported modules under -dynamic-too compilation. It probably
should be changed to handle imports uniformly. It looks like
dynamic-too support was bolted on to a system
Agreed, let's do it. Thanks for the well-argued proposal.
Next up: consistent style :-)
Cheers,
Simon
On 27/06/2014 10:51, Johan Tibell wrote:
Hi!
I found myself exploring new parts of the GHC code base the last few
weeks (exciting!), which again reminded me of my biggest frustration
when
I'm not sure of the correct way to fix this either - Simon, what do you
think? This is a regression in 7.8 relative to 7.6 which unfortunately
wasn't caught by the test suite. The commit that broke this fixed
something else, so it's not a simple matter of reverting it.
Vitaly, one concrete
The s/r conflicts can also be a problem, depending on what you're trying
to parse. It's generally a good idea to get rid of them if you can, but
at the least you should understand why they exist (use happy --info) and
document them in Parser.y.pp.
Cheers,
Simon
On 30/06/2014 14:04, Simon
The problem is that this instruction requires three separate registers,
but cmpxchgl already reads and writes %eax leaving only two free
registers (%ecx and %edx).
You'll need to arrange to not use the complicated addressing modes with
cmpxchg on i386, and keep the number of free regs
On 27/06/2014 12:23, Johan Tibell wrote:
On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow marlo...@gmail.com wrote:
The problem is that this instruction requires three separate registers, but
cmpxchgl already reads and writes %eax leaving only two free registers (%ecx
and %edx).
You'll need
:
I read the friendly Arcanist manual and I wonder if we intend
to have a
default .arcconfig file in the GHC repo? From the docs it seems
like a good
idea.
Janek
Dnia wtorek, 17 czerwca 2014, Simon Marlow napisał:
On 13/06/14 10:47, Jan Stolarek wrote
On 25/06/2014 15:28, Ömer Sinan Ağacan wrote:
I'm running this program:
{-# LANGUAGE DeriveDataTypeable, ScopedTypeVariables #-}
import GHC.Stack
import Control.Exception.Base
import Data.Typeable
data MyException = MyException deriving (Show, Typeable)
instance Exception
to
low level cmm.
Thanks,
Yuras
On Fri, 2014-06-20 at 21:24 +0100, Simon Marlow wrote:
On 20/06/14 15:03, Yuras Shumovich wrote:
Hello,
I'm trying to do safe ccall from cmm (see below for the code). It seems
to work, but -dcmm-lint is not satisfied:
/opt/ghc-7.8.2/bin/ghc --make -o test hs.hs
Image macros are part of the charm of using Phabricator, and (IMO of
course) they inject a little essential humour into the code review
process. You don't have to use them, of course!
I don't think there's a way to actually not display them, although you
could probably install adblocker and
On 17/06/14 20:53, Simon Peyton Jones wrote:
I would require a lot of convincing that we wanted Uniques for RdrNames. I
seriously doubt that, once the dust has settled, you'll need a finite map
indexed by RdrNames. But even if you do, you could use a TrieMap-like
structure.
I must be
niedziela, 8 czerwca 2014, Simon Marlow napisał:
On 07/06/2014 07:21, Manuel M T Chakravarty wrote:
So, why not put everything on GutHub and use pull requests and so on?
github just isn't great for doing code reviews. No side-by-side diffs,
and it sends you a separate email for every single comment
The motivation for this design is to make it so that
let
f = \x . E
in
... f y ...
Gives the same call stack as
... (\x . E) y ...
That is, inlining a function does not change the call stack. GHC
assumes that this is valid, so the call stack semantics should reflect that.
tl;dir I strongly support this, but for code review only, and only if we
can integrate it well with Trac.
Phabricator is what we use internally at Facebook, and it's a really
good code review tool (better than github, IMO). For one thing, you
only get one email for a complete review, rather
Rather than marking T8832 as broken, we should just have the 32-bit
output. I believe you can put it in the file T8832.stdout-ws-32.
On 03/06/2014 07:06, transfuturist wrote:
---
testsuite/tests/rts/all.T | 3 +++
testsuite/tests/simplCore/should_compile/all.T | 3 ++-
I don't know what this does, and there doesn't seem to be any info in
#8520 either.
Could you add the patch to the ticket, and help us out by saying why
this fixes the problem (and if possible, explain why it won't break
anything else)?
On 03/06/2014 07:06, transfuturist wrote:
---
I'd say (1) and (3) are good, but we typically don't do (2) in the compiler.
On the other hand, if you want to export a clean and self-contained API
for the parser from the GHC module, I think that would be great. There
is GHC.parser for parsing a whole module, but I'm sure a more complete
We could probably remove that check.
Cheers,
Simon
On 02/06/2014 19:09, Edward Z. Yang wrote:
Hello Ömer,
That does seem pretty suspicious. My interpretation is that
ccs should just never be EMPTY_STACK. If we look at the calling
codepaths, the only case that a NULL could be passed is if
On 15/05/2014 11:12, Herbert Valerio Riedel wrote:
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
On 28/05/2014 12:16, Edward Kmett wrote:
How hard /would/ it be to replace the global weak pointer lock with
something that scales better?
I'm looking at switching some of my older BDD code into Haskell.
To do so I'd love to be able to use an intuitive weak-pointer based
cache management
Please record the repro steps exactly, including the git hashes of any
repositories that you use. If it is a GC bug, the last thing we want is
for it to disappear, because then we lose the opportunity to find it.
If you could put the build steps into a script that we can run to
reproduce the
On 24/05/2014 01:11, Luite Stegeman wrote:
In particular, the variant of weak reference you suggest is the
/ephemeron/ semantics in Hayes. Their reachability rule is:
The value field of an ephemeron is reachable if both (a) the
ephemeron (weak pointer object) is
On 18/05/2014 15:20, Ömer Sinan Ağacan wrote:
Thanks again for the answer.
Not sure what _call_ is suppose to be. What's the context?
In Simon Marlow's slides, stack traces are implemented in terms of
call and push operations. I guess `push` in STG syntax is stands
for push operation
It looks like I accidentally slipped that fix in with the allocation
counters patch, and when the patch was reverted the fix was reverted
too. I'll commit the fix from the patch (which is probably better,
that's what I intended to do all along).
Sorry for the mixup!
Simon
On 13/05/14
static initializers in
the linker so it might work now.
Cheers,
Simon
On Mon, May 5, 2014 at 4:58 PM, Simon Marlow marlo...@gmail.com wrote:
On 03/05/14 04:15, Dominick Samperi wrote:
I'm trying to understand the dynamic linking situation with the help of
https://ghc.haskell.org/trac/ghc
Sounds like a great idea! I'll be around to answer questions.
Cheers,
Simon
On 07/05/2014 13:54, Joachim Breitner wrote:
Dear fellow deverlopers,
I’ll be attending ZuriHac in a month time, without a project of my own
that I plan to pursue. Hence I’m considering to run a “GHC bug
squashing”
On 04/05/14 11:10, Johan Tibell wrote:
I found myself needing atomic operations on basic, mutable numeric
values. I wrote a short design doc that I'd like feedback on:
https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops
I will try to implement these for 7.10.
Right now, all
is that my experience under Windows
is the opposite of the negative experience described on this
page. What I mean by this is more versions of ghci seem to
work under Windows (correctly linking to R.dll) than work
under Linux!
On Fri, May 2, 2014 at 3:45 PM, Simon Marlow marlo...@gmail.com wrote:
Can
* work,
even with 7.6.3. What goes wrong in that case?
Cheers,
Simon
merely that theres no way to get llvm-general to work on ghci in 7.6 afaik
On Mon, May 5, 2014 at 4:54 PM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
I don't see any reason why llvm-general
of linking not working in ghci, But
it could be that didn't try the -fshared-llvm + ghci in 7.6
On Mon, May 5, 2014 at 5:01 PM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
On 05/05/14 21:58, Carter Schonwald wrote:
no, i was saying LLVM-General when static linked
On 04/05/14 16:45, Sergei Trofimovich wrote:
On Sun, 4 May 2014 09:34:16 +0100
William Kenyon g...@abacathoo.org wrote:
I tested my patch on an old 32 bit laptop over night and it didn't work.
I think it's best to revert Simon's patch and let him fix it when he gets
chance.
On 3 May 2014
custom linker.
-Edward
On Thu, May 1, 2014 at 5:30 PM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
On 01/05/14 15:27, Edward Kmett wrote:
Figured I'd make one case for dynamic linking:
https://github.com/ekmett/__rounded
https
On Fri, May 2, 2014 at 9:47 AM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
On 02/05/2014 14:28, Edward Kmett wrote:
Perhaps. We actually tried that originally, but had issues about
where and how to get cabal to place it. We'd need it to go somewhere
installed
how to check that this is so.
Nevertheless, I checked
the linking issue and it is NOT fixed with this build, so
DYNAMIC_GHC_PROGRAMS=YES is required to prevent the problems
reported by me and others.
On Fri, May 2, 2014 at 9:09 AM, Simon Marlow marlo...@gmail.com wrote:
On 02/05/2014 01:09
here.
Thanks,
Dominick
On Thu, May 1, 2014 at 5:27 PM, Simon Marlow marlo...@gmail.com wrote:
On 01/05/14 14:48, Dominick Samperi wrote:
The problem with some graphics libraries used via FFI (and other libraries
that are not thread-safe), if I understand the situation correctly, is
that ghci
to the library like normal
rather than link it in directly, but it isn't clear to me what would
happen even with those hooks if we rolled back to something like the old
custom linker.
-Edward
On Thu, May 1, 2014 at 5:30 PM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
On 01/05
on
unregisterised platforms. In 7.8, GHCi and TH now works on some
platforms where it didn't before (albeit not very widely used platforms).
Cheers,
Simon
On Wed, Apr 30, 2014 at 1:45 PM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
On 30/04/2014 01:35, George Colpitts
On Wed, Apr 30, 2014 at 1:45 PM, Simon Marlow marlo...@gmail.com wrote:
On 30/04/2014 01:35, George Colpitts wrote:
It doesn't have anything about the dynamic linking changes made for 7.8.
I think it's worth mentioning the improvements we expect to get from
that. The highlights of the release notes
On 30/04/2014 01:35, George Colpitts wrote:
It doesn't have anything about the dynamic linking changes made for 7.8.
I think it's worth mentioning the improvements we expect to get from
that. The highlights of the release notes do mention it, so maybe that
suffices.
In particular, I'm hoping
On 29/04/2014 10:58, Herbert Valerio Riedel wrote:
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
We should reject LLVM 3.2 if it's known to be bad - I remember running
into this on the RPi too. LlvmCodeGen already checks the version number
and emits warnings if it's too old or too new.
On 24/04/2014 20:04, Austin Seipp wrote:
GHC 7.6 did not support LLVM 3.2 - it was only tested with
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 the git.haskell.org/ghc repos, but they would become
lagging repos
On 28/04/2014 09:32, Herbert Valerio Riedel wrote:
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
if
theres any docs convention for the C code in ghc,
perhaps simon marlow or austin can chime in?
On Thu, Apr 24, 2014 at 12:45 PM, Howard B. Golden
howard_b_gol...@yahoo.com mailto:howard_b_gol...@yahoo.com wrote:
Hi, I am working on a patch for GHC Trac ticket #9021. I wonder
whether it would
Could we have a comment with the ticket number next to the prototype
please? Otherwise some well-meaning developer will fix it again in
the future :-)
Cheers,
Simon
On 22/04/2014 05:40, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
This reminds me: the instructions shouldn't be recommending that people
add GHC's own mingw tools to their PATH. The build should work without
that, and indeed we want to know if the build is using gcc from PATH
because that's a bug (and could cause real problems).
Cheers,
Simon
On
On 15/04/14 05:52, Jan Stolarek wrote:
I think Simon Marlow is even more conservative, and
does his validate builds in a separate tree so he catches missing files.
I thought everyone is doing that.
It's the recommended workflow, but I must admit it doesn't always work
out, and nowadays I
, would you like to go ahead and do that?
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon
| Marlow
| Sent: 18 April 2014 21:32
| To: Austin Seipp
| Cc: ghc-devs@haskell.org
| Subject: Re: Heap usage of GHC increased in 7.8 vs. 7.6
|
| On 18
should revisit it when the
numbers are solid. I honestly don't know what all the expected
intra-module changes might be (I've CC'd Edward in case he'd like to
chime in about that.)
On Fri, Apr 18, 2014 at 10:39 AM, Simon Marlow marlo...@gmail.com wrote:
I noticed that T1969 is failing again
Thanks Edward. Austin, can you cherry-pick this for 7.8.3 please?
Cheers,
Simon
On 13/04/2014 07:37, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
On 08/04/2014 09:30, Joachim Breitner wrote:
we also need a culture of just doing stuff, and less asking for it.
Where is the like button on this line?
+1
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
On 08/04/2014 09:58, Joachim Breitner wrote:
Hi,
Am Dienstag, den 08.04.2014, 10:31 +0200 schrieb Herbert Valerio Riedel:
Just a reminder, as not everybody may be aware yet:
There's already daily GHC HEAD packages for Debian at
http://deb.haskell.org/
thanks for the reminder. I guess I
On 10/04/2014 08:58, Simon Peyton Jones wrote:
Friends
The thread below concerns GHC's performance. I'm writing to ask for your help.
In developing GHC we always run 'validate', which runs a lot of regression
tests. A few of those are performance tests, but because we do so frequently,
none
On 11/04/2014 11:55, Johan Tibell wrote:
On Fri, Apr 11, 2014 at 10:58 AM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
Let me second this. In particular, I think we regress on GHC
performance regularly, because the perf tests just aren't a good way
to prevent
f65e9fe435a72ac3de1487a3e5a24b347c1a809b Mon Sep 17 00:00:00 2001
From: Simon Marlow marlo...@gmail.com
Date: Fri, 4 Apr 2014 17:02:20 +0100
Subject: [PATCH] Disable thin archive support on Windows
---
rts/Linker.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/rts/Linker.c b
On 24/03/2014 06:49, kyra wrote:
On 3/23/2014 20:51, Jost Berthold wrote:
Hello,
With the patch to deriveConstants, a build on an older Windows (32bit
Vista, MinGW32 installation, which used to work) now fails with error
Can't find STD_HDR_SIZE
Same here: Windows 64-bit, MSYS2, nm being
Ok, I buy the argument that if we're already compiling everything, we
shouldn't have to re-typecheck it all in Haddock. Of course if you're
*not* already compiling everything, then the argument doesn't apply:
Haddock does support generating documentation from source files without
precompiling
On 18/03/2014 18:20, Mateusz Kowalczyk wrote:
Hi all,
I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox
and it reminded me of something I've been wondering for a while: why do
we not store Haddock docstrings in the interface file?
I think that if we did, we could do some
On 18/03/2014 11:42, Yuras Shumovich wrote:
On Tue, 2014-03-18 at 12:37 +1100, Manuel M T Chakravarty wrote:
Library implementation can't generate native dynamic wrapper, it has to
use slow libffi.
When we first implemented the FFI, there was no libffi. Maintaining the
adjustor code for all
On 10/03/2014 19:58, Sergei Trofimovich wrote:
On Mon, 10 Mar 2014 18:59:38 +0100
Johan Tibell johan.tib...@gmail.com wrote:
Added:
https://github.com/ghc/ghc/commit/ddf79ebf69fe4a6e69d69d451a6040a53b1ea12c
While at it:
SRC_HC_OPTS= ... -H64m
Just wondering: that '-H64m' is from
On 18/03/2014 01:37, Manuel M T Chakravarty wrote:
Yuras Shumovich shumovi...@gmail.com:
I think the compiler is the right place. It is impossible to have
efficient implementation in a library.
For dynamic wrapper (foreign import wrapper stuff) ghc generates piece
of executable code at
201 - 300 of 470 matches
Mail list logo
