Lots of validate failures today (x86-64/Linux):
Unexpected failures:
indexed-types/should_compile Gentle [exit code non-0] (normal)
perf/compilerT5030 [stat not good enough]
(normal)
polykindsT6068 [bad stderr] (ghci)
-boun...@haskell.org [mailto:ghc-commits-
| boun...@haskell.org] On Behalf Of Simon Marlow
| Sent: 17 January 2013 12:57
| To: ghc-comm...@haskell.org
| Subject: [commit: ghc] master: Tidy up cross-compiling (109a1e5)
|
| Repository : ssh://darcs.haskell.org//srv/darcs/ghc
|
| On branch : master
On 17/01/13 14:06, Simon Peyton-Jones wrote:
Hmm. Precisely because it causes un-forced conflicts, our policy has been:
de-tab when you are modifying a file anyway
But if you find files that are stable -- have not been modified for some months
-- then yes you could detab them. Perhaps
On 17/01/13 14:08, Simon Marlow wrote:
On 17/01/13 14:00, Simon Peyton-Jones wrote:
Would it be worth transferring that comment into the building guide (a
cross-compiling page perhaps). The distinction is subtle and the
information is useful
There is http://hackage.haskell.org/trac/ghc/wiki
On 18/01/13 15:25, Stephen Paul Weber wrote:
Somebody claiming to be Simon Marlow wrote:
Ok, new wiki page is here:
http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling
Is:
--with-gcc=gcc --with-ld=ld --with-nm=nm --with-objdump=objdump
Necessary? I guess if the given tools
On 18/01/13 16:45, Simon Peyton-Jones wrote:
| In Packages we have a dflags with an error thunk in it for pkgState,
| and it's the strict evaluation of that pkgState that is changing the
| behaviour.
|
| Whereabouts are we evaluating it? Could we fix that instead?
That would be good. It's
On 30/01/13 01:20, Ian Lynagh wrote:
On Fri, Jan 18, 2013 at 05:03:26PM +, Simon Marlow wrote:
On 18/01/13 16:45, Simon Peyton-Jones wrote:
| In Packages we have a dflags with an error thunk in it for pkgState,
| and it's the strict evaluation of that pkgState that is changing
--include mk/build.mk
+-include mk/$(CrossCompilePrefix)build.mk
endif
ifeq $(BINDIST) YES
On 2/1/13, Simon Marlow marlo...@gmail.com wrote:
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset
On 05/02/13 10:34, Geoffrey Mainland wrote:
On 02/05/2013 09:06 AM, Simon Marlow wrote:
On 05/02/13 00:36, Geoffrey Mainland wrote:
On 02/04/2013 11:56 PM, Johan Tibell wrote:
On Mon, Feb 4, 2013 at 3:19 PM, Geoffrey Mainland
mainl...@apeiron.net wrote:
What would a sensible fallback
On 06/02/13 16:04, Johan Tibell wrote:
On Wed, Feb 6, 2013 at 2:09 AM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
This is slightly off topic, but I wanted to plant this thought in
people's brains: we shouldn't place much significance in the average
of a bunch
On 06/02/13 22:26, Andy Georges wrote:
Quantifying performance changes with effect size confidence intervals - Tomas
Kalibera and Richard Jones, 2012 (tech report)
This is a good one - it was actually a talk by Richard Jones that
highlighted to me the problems with averaging over benchmarks
On 08/02/13 10:10, Nicolas Frisby wrote:
Hi Johan. I'm seeing much different numbers when I test for regressions.
Also 64-bit Linux.
Could you explain your method? Origin of the GHC/libraries you're
measuring and the options your running NoFib with? Thanks.
I'm using the 28 Jan
On 08/02/13 14:19, Ian Lynagh wrote:
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/478da8fea8c7aca287a0a6270e20254221c60c84
---
commit
a large number of packages on Hackage?
Manuel
Johan Tibell johan.tib...@gmail.com mailto:johan.tib...@gmail.com:
On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
For a while we've been doing one major release per year, and 1-2
minor
?
Simon
*From:*Mark Lentczner [mailto:mark.lentcz...@gmail.com]
*Sent:* 09 February 2013 17:48
*To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon
Peyton-Jones; Mark Lentczner; andreas.voel...@gmail.com; Carter
Schonwald; kosti...@gmail.com; Edsko de Vries; ghc-devs@haskell.org;
glasgow
On 08/02/13 17:44, Johan Tibell wrote:
Hi,
Simon M asked me to check if -fregs-graph has regressed in HEAD. It
looks like it has:
HEAD vs HEAD with -fregs-graph:
snip
Look at n-body and fannkuch-refux (two of the shootout benchmarks). I
know containers uses -fregs-graph, so perhaps those
On 12/02/13 03:17, Johan Tibell wrote:
Hi Nicolas!
I tried to reproduce the difference between 7.0.4 and 7.6.2 on the
exp3_8, wheel-sieve1, and primes and couldn't get the same percent
difference as you. We need to reconcile these differences somehow. Lets
start with more exact machine specs. I
On 13/02/13 07:06, wren ng thornton wrote:
On 2/12/13 3:37 AM, Simon Marlow wrote:
One reason for the major version bumps is that base is a big
conglomeration of modules, ranging from those that hardly ever change
(Prelude) to those that change frequently (GHC.*). For example, the new
IO
On 13/02/13 21:47, Gabor Greif wrote:
On 2/13/13, Sergei Trofimovich sly...@gmail.com wrote:
From: Sergei Trofimovich sly...@gentoo.org
Fixed bootstrap failure on linux for --target=mingw32
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
configure.ac | 10 --
1 file
On x86_64/Linux:
Unexpected passes:
perf/should_run T149 (normal)
Unexpected failures:
perf/compiler T3064 [stat too good] (normal)
perf/haddock haddock.Cabal [stat not good enough] (normal)
perf/haddock haddock.base [stat not good enough]
On 14/02/13 11:55, Alexander Kjeldaas wrote:
I was looking at the eventlog code, and I wanted to move processing of a
full eventlog buffer into Haskell, instead of the now fixed behavior of
writing the data to a file.
To do this, I though that having a haskell process blocked on an MVar,
or
On 14/02/13 20:54, Alexander Kjeldaas wrote:
I ended up staring at the PrimOps.cmm file today, and porting tryPutMVar
to C so it can be used from the RTS.
During my staring, it occurred to me that it should be possible to
implement a wait-on-multiple MVars with mostly no overhead. I am
On 15/02/13 20:31, Johan Tibell wrote:
On Fri, Feb 15, 2013 at 12:02 PM, Nicolas Frisby
nicolas.fri...@gmail.com mailto:nicolas.fri...@gmail.com wrote:
Thanks for rallying everyone! I made a bit of a breakthrough while
trying to pinpoint where the linker is invoked.
Here's the
On 17/02/13 16:41, Nicolas Frisby wrote:
I've noticed some suspicious code in base:GHC.IO.Encoding.
setLocaleEncoding, setFileSystemEncoding, setForeignEncoding ::
TextEncoding - IO ()
(getLocaleEncoding, setLocaleEncoding) = mkGlobal
initLocaleEncoding
On 18/02/13 14:02, Edsko de Vries wrote:
Dear Simon, other ghc devs,
I hooked into genericHscRecompile to traverse the typechecked source and
construct an environment of type
[(SrcSpan, Id)]
recording all identifiers in the source with their type, definition
site, etc. To be precise, I
On Mon, Feb 18, 2013 at 2:19 PM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote:
On 16/02/13 16:32, Nicolas Frisby wrote:
I noticed some suspicious wiggling in my ticky reports' entry
counts.
SPJ suggested they were due to the counter ticking before
. We like to keep you on your toes! (Actually this is
probably because the nofib build system is a snapshot of an old GHC
build system, and at some point we consistently renamed lots of make
variables to be FOO_CMD in GHC).
Cheers,
Simon
On Mon, Feb 18, 2013 at 2:12 PM, Simon Marlow
I'm also puzzled about why this has started to happen for you. It
hasn't happened for me, but I have libtool installed. We don't use
libtool in GHC.
Is this on Linux?
Cheers,
Simon
On 27/02/13 11:20, Simon Peyton-Jones wrote:
Is this new? Does it matter? Can I ignore it? Does
On 27/02/13 16:17, Joey Adams wrote:
On Sun, Feb 24, 2013 at 3:40 PM, Gabor Greif ggr...@gmail.com
mailto:ggr...@gmail.com wrote:
Hi all,
from what I gathered so far no emission of write barriers is needed when
- running on a uniprocessor (-threaded or not)
- running on a
On 15/03/13 12:54, PHO wrote:
I found the HEAD stopped working on MacOS X 10.5.8 since the parallel
I/O manager got merged to HEAD. Stage-2 compiler successfully builds
(including Language.Haskell.TH.Syntax contrary to the report by Kazu
Yamamoto) but the resulting binary is very unstable
On 11/03/13 03:17, Akio Takano wrote:
Hi,
I'm working on implementing per-generation lists of weak pointers to
speed up garbage collection in programs that allocate a lot of weak
pointers. I have a patch [1] that validates and gives a 3x speed up on
a benchmark. However I'd like to ask for some
On 25/03/13 10:35, Nicolas Frisby wrote:
(I admit that I remain intimidated by the build system.)
I'm renabling some ticky counter bumps from within the RTS. The most
direct path I see to this involves adding -ticky to makefile variables
such as WAY_debug_HC_OPTS. (See the APPENDIX for why I
A quick answer is that I put some documentation at the top of
compiler/cmm/CmmParse.y that explains the new syntax. That should help
you get to grips with the changes.
Cheers,
Simon
On 06/04/13 13:48, Simon Peyton-Jones wrote:
Simon Marlow is the man who will really know. He's
On 22/03/13 21:26, Jason Dagit wrote:
I had never heard of BEX/BEX64 errors before. Naturally I wanted to know
what it was. Perhaps others here have never heard of this as well? Just
in case, I'll share what I learned.
After a bit of digging I came across this:
On 12/04/13 05:51, Gabor Greif wrote:
On 4/9/13, Gabor Greif ggr...@gmail.com wrote:
On 4/9/13, Trevor Elliott tre...@galois.com wrote:
So this did something different, but still tries to build tools like
hsc2hs with the stage1 compiler. This won't really work for a target
like the HaLVM, as
On 28/03/13 08:04, Nicolas Frisby wrote:
Hi all. I'm prepping for my first GHC commit, so I'm paying attention to
all the details.
I'm following the workflow described here
http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Workflowwithvalidate
And I have a couple questions.
On 15/04/13 22:25, Trevor Elliott wrote:
In retrospect I should have used a different name. Feel free to fix it
(and the wiki page).
I've created a ticket with a patch that I think addresses this issue
[1]. The patch adds a mechanism that allows packages and programs to be
disabled when
On 30 April 2013 19:03, Trevor Elliott tre...@galois.com wrote:
I'm a bit confused - what is the issue that you want to fix? The fix
I suggested was to change the name of Stage1Only to more closely reflect
what it actually does: disable the building of the stage 2 compiler
*binary* but not
Akio, I looked at your first patch, which mostly seems good. The
sequence at the beginning of deRefWeak certainly looks strange - I think
it's ok, but it needs a comment.
One thing I'm confused about is the handling of DEAD_WEAK pointers. You
removed the StgDeadWeak struct - how is that
On 24/04/13 07:52, Jan Stolarek wrote:
Is there a way of measuring how often such a rule is triggered? I think no
programmer will write a
program which explicitly compares two floating point literals, but I'd like to
know how often
such cases result from program transformation.
Cases like
On 25/04/13 13:14, Páli Gábor János wrote:
On Thu, Apr 25, 2013 at 12:36 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
I'm sure that I don't set the CC environment variable. And specifying
CC=gcc47 does not solve this.
That is probably because you should set it to $LOCALBASE/bin/gcc47,
e.g.
On 26/04/13 06:32, Johan Tibell wrote:
On Thu, Apr 25, 2013 at 9:51 PM, Bryan O'Sullivan b...@serpentine.com wrote:
On Thu, Apr 25, 2013 at 4:01 PM, Johan Tibell johan.tib...@gmail.com
wrote:
I think you could make up a case where it is a loss. It would boil down to
repeated reboxing of a
On 09/05/13 01:36, Austin Seipp wrote:
Hello all,
On IRC today, Nicolas Trangez brought up the idea of registering GHC
for Coverity's SCAN project. SCAN is essentially a free service run by
Coverity, which runs their Static Analyzer on open source projects
('open source' being defined by OSI)
+1. I don't have any comments on the technical issues I'm afraid, but
the more ways we can extend GHC without having to change it directly,
the better.
Cheers,
Simon
On 05/06/13 12:51, Edsko de Vries wrote:
Sorry for the earlier mishap, here's the full email.
Hi all,
The plugin
On 05/06/13 14:01, Edsko de Vries wrote:
Hi all,
This proposal is related to
http://hackage.haskell.org/trac/ghc/ticket/1381, which Simon Marlow
closed through commit
https://github.com/ghc/ghc/commit/02c4ab049adeb77b8ee0e3b98fbf0f3026eee453.
The problem, in a nutshell, is how do we terminate
On 05/06/13 16:59, Ian Lynagh wrote:
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we are in this situation of half
submodules, half random-floating-git-repository-checkouts?
On 08/06/13 08:38, Geoffrey Mainland wrote:
On 06/06/2013 09:44 PM, Simon Marlow wrote:
On 05/06/13 16:59, Ian Lynagh wrote:
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we
The issue that we hit sooner than this is that when we build a
cross-compiler, we build all the libs for the target platform and not
the host platform (see
http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation). So to make
TH work, we have to change the way we build cross compilers, and
On 09/06/13 17:51, Ian Lynagh wrote:
On Sun, Jun 09, 2013 at 11:15:37AM -0500, Austin Seipp wrote:
I'm referring to Joachim Breitner's work on
splitting the base.
So what's the timeline here?
As soon as possible after 7.8 is branched.
Has there been a decision somewhere on what to do?
Hi Trevor,
That all sounds good to me. By all means go ahead and submit patches,
I'll be happy to review them.
Cheers,
Simon
On 24/06/13 19:46, Trevor Elliott wrote:
Hi Simon,
Sorry about my late response, I haven't had much time to experiment
recently.
Making with stage=1
Geoff - is it possible that this problem might be caused by time skew
between NFS servers? Are any parts of the build, or files accessed by
it, on NFS?
Cheers,
Simon
On 24/06/13 23:44, Geoffrey Mainland wrote:
On 06/24/2013 09:21 PM, Jan Stolarek wrote:
My only claim was that I
On 26/06/13 04:13, Austin Seipp wrote:
Thanks Manuel!
I have an update on this work (I am also CC'ing glasgow-haskell-users,
as I forgot last time.) The TL;DR is this:
* HEAD will correctly work with Clang 3.4svn on both Linux, and OS X.
* I have a small, 6-line patch to Clang to fix the
wrote:
A UniqSupply has a single shared Int behind the scenes, so it’s really
no different.
Simon Marlow may want to comment on your proposed solutions. Personally
I think Option 1 is most attractive. Yes, the API changes, but in a
decent way and one that may be useful for other things.
Now I think
On 08/07/13 11:14, Erik de Castro Lopo wrote:
Hi all,
I've added a feature request ticket to the GHC trac:
http://ghc.haskell.org/trac/ghc/ticket/8043
for qualified module exports. In a nutshell this would allow the
following 'qualified module' export eg:
module MyModule
(
1. Was a quick hack that I did sometime in the past, it probably didn't
work fully. Nowadays LLVM does loopification, so its not clear whether
there's any benefit to doing it in cmm (but maybe there's some other payoff
that we can get by doing it earlier).
2. Is Edward Yang's optimisation pass.
-
| From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
| On Behalf Of Jan Stolarek
| Sent: 12 July 2013 09:20
| To: Simon Marlow
| Cc: ghc-devs@haskell.org
| Subject: Re: Some more questions about Cmm pipeline
|
| I have two more questions:
|
| 3. I will be doing copy propagation
Ian,
You've done wonders for GHC during your time with us, and you'll be a
tough act to follow. Best of luck with your future endeavours!
Cheers,
Simon
On 18/07/13 15:44, Ian Lynagh wrote:
Friends,
For a number of reasons, I have decided to move on to new challenges,
and so from
On 18/07/13 14:17, Ryan Newton wrote:
The atomic-primops library depends on symbols such as
store_load_barrier and cas, which are defined in SMP.h. Thus the
result is that if the program is linked WITHOUT -threaded, the user
gets a linker error about undefined symbols.
The specific place it's
I got this from a git push today:
$ git push
Counting objects: 17, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (11/11), 1.20 KiB, done.
Total 11 (delta 6), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote:
On 20/07/13 07:28, Ryan Newton wrote:
Hi Simon,
That sounds like a good solution and I'll attempt a patch. I think the
fix is only three lines. That is, replace these three lines with
EXTERN_INLINE C functions:
#define write_barrier() /* nothing */
#define store_load_barrier() /*
I tried and failed to push to the testsuite repo today.
$ git push
Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 695 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
error: insufficient permission for
A validate today on x86_64/Linux is failing with
haddock: internal error: synifyKind
While haddocking the base package. Anyone know why?
Cheers,
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
Right - I made a lot of changes while working on the new codegen.
Norman signed off on them (in principle at least) so it should be fine
to upload the package. I should admit I did very limited testing
outside of GHC's use case, and GHC even contains a copy of some of the
hoopl code with its
On 26/07/13 22:56, Edward Z. Yang wrote:
Thank you Edward. I am aware of these requirements - my problem is writing the
code in which these
will always hold (I'm optimizing Cmm and hand-written Cmm files tend to cause
many problems that
don't appear in automatically generated Cmm). Having a
On 10/08/13 00:58, Edward Z. Yang wrote:
How would people feel about an alternate GC implementation in GHC which
is not parallel? A GC like this would be simpler to understand, maybe a
little faster when parallel collection is not being used, and (most
importantly for my case) easier to extend
It's probably best not to rely on external libraries for this.
I'd be happy with representing the options as data rather than code,
along with a generic parser. Performance is very likely a non-issue,
but you could always do something really simple like bucketing the
options based on the
Just in case there are other people (like me) who didn't notice this,
the syntax for telling git that you want to update a Trac ticket in the
commit log has changed. Read Herbet's message for details.
I used to just mention the ticket number in the commit message blah
blah (#1234), the new
On 13/08/13 13:03, Jan Stolarek wrote:
I have yet another Hoopl question. One of my rewrites allocates a new unique
local register and this register is later added as a fact. So I have Cmm code
that looks like this:
I32[(old + 4)] = complicated_expr
which is rewritten to:
newReg1 =
On 15/08/13 14:36, Herbert Valerio Riedel wrote:
Hello Simon,
On 2013-08-15 at 04:26:38 +0200, Simon Peyton-Jones wrote:
My gut feel is that it's fragile and unexpected to have tickets change
status based on commit messages. Revisiting the ticket itself can
remind you
that the fix is only
On 13/08/13 14:15, Edward Z. Yang wrote:
But perhaps there's another way to achieve your goals - what are the
interesting features you want to add?
Yeah. The key thing I need to change is how the GC decides where
live objects are evacuated to, to support a more efficient implementation
of
On 19/08/13 21:16, Carter Schonwald wrote:
hey all,
i'm trying to build head to test out some stuff, and i'm hitting the
following error message (http://ghc.haskell.org/trac/ghc/ticket/8143 )
compiler/stage1/build/Parser.hs:1:1:
File name does not match module name:
Saw: `Main'
On 20/08/13 12:21, Geoffrey Mainland wrote:
Would be nice to have. How about a third hook that disallows commits
that include whitespace-only changes unless *all* changes are
whitespace-only? ;)
The problem with these kind of commit-time checks is that you only find
out the problem *after*
On 21/08/13 15:44, Ryan Newton wrote:
Hi all,
Returning to the topic discussed by Simon M. and others here:
http://projects.haskell.org/pipermail/haskell-platform/2009-July/000572.html
This is my attempt at a script for bootstrapping a GHC-validating VM:
On 21/08/13 16:11, Ryan Newton wrote:
Hi all,
It is not merged into master presently but I would like to propose the
three new primops that are on the atomics branch for inclusion in 7.8.
These are pretty much completely apart from everything else and don't
break any existing code.
For the
Hi Jan,
On 22/08/13 14:01, Jan Stolarek wrote:
Me and Simon PJ had some discussion about modifying Hoopl. I summarized that
discussion on a wiki page:
http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup
I'd like to implement changes once there's a consensus on which changes exactly
do we
Sorry! Just pushed the fix. atomicinc was also failing for me, I
assumed it was nothing to do with me. Perhaps not. I'll look into it.
Cheers,
Simon
On 22/08/13 19:35, Austin Seipp wrote:
Simon,
While validating the changes for #8144, I noticed there were several
failures that
Fixed atomicinc too.
Cheers,
Simon
On 22/08/13 19:58, Simon Marlow wrote:
Sorry! Just pushed the fix. atomicinc was also failing for me, I
assumed it was nothing to do with me. Perhaps not. I'll look into it.
Cheers,
Simon
On 22/08/13 19:35, Austin Seipp wrote:
Simon
On 22/08/13 19:24, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/testsuite
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/a5875c4e4fb83993142c8e8294b47516adf6a77f/testsuite
---
..' is probably good enough.
Cheers,
Simon
Alternatively, these could be pre-commit hooks in the developer
repository, but I believe you have to opt into that. Maybe worth putting
on the wiki, though.
On Thu, Aug 22, 2013 at 2:33 AM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com wrote
On 22/08/13 15:31, Simon Peyton-Jones wrote:
| Oh, and I think that using sameTVar# for primop and sameTVar for wrapper
| is a good choice, even if we make transition slightly more difficult.
| This naming feels better to me
You said that before, but *why* does the naming feel better to you?
On 24/08/13 23:08, Edward Z. Yang wrote:
Part of the resource limits work needs to access the bdescr for a thunk
when it is entered. Of course, right now, this needs to go through
HEAP_ALLOCED; I imagine this would way to slow to put into the generated
code. So I happened across this page
On 26/08/13 09:50, Jan Stolarek wrote:
I don't mind breaking these very low-level APIs.
We are breaking that API at the moment, except that you propose to break it by
chnaging type
signatures, whereas I chose to break it by changing names. So currently the
change in primops
will not go
On 26/08/13 10:38, Jan Stolarek wrote:
So since we have to break the API anyway, why not break it in the way
that we want?
Oh, but the thing is we don't! We have a plan to rename GHC.Prim to
GHC.Prim.BuiltIn, rename
GHC.PrimWrappers (in ghc-prim) to GHC.Prim and make it re-export
Nice catch!
On 28/08/13 09:08, Simon Peyton-Jones wrote:
Friends
My Windows build (new laptop) got stuck again, but this time I managed
to work out what is going on. This email is just to record the issue;
I’ll add something to the wiki.
*tl;dr:* a MSYS build will fail in a deeply strange
That's the bug. Fix coming!
Simon
On 02/09/13 05:46, Austin Seipp wrote:
I (think) I see the problem, but maybe I'm just tired and shooting in the dark.
The only time checkUnload really iteratively calls free is in
CheckUnload.c (I say 'iteratively', because the fact you're
touching/freeing
On 30/08/13 23:04, Austin Seipp wrote:
I believe they simply weren't regenerated. The mailing lists are a bit
off right now and I haven't had time to sit down and deal with them
for a few hours yet.
Just regenerating cvs-ghc on the main server should be easy enough though.
I'd be really
On 03/09/13 22:57, Johan Tibell wrote:
Hi Kazu,
On Tue, Sep 3, 2013 at 2:52 PM, Kazu Yamamoto k...@iij.ad.jp
mailto:k...@iij.ad.jp wrote:
Hi,
As I said before, I started running HTTP server using Mio in the real
world. Unfortunately, the daemon is not stable.
After one day or
On 09/09/13 08:14, Edward Z. Yang wrote:
Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 19:36:19 -0700 2013:
% make show VALUE=GhcLibWays
make -r --no-print-directory -f ghc.mk show
GhcLibWays=v p dyn
Yes, it looks like you are missing p_dyn from this list. I think
this
linker patches that are landing soon we are not too far off
from
having this work.
Edward
[1] http://ghc.haskell.org/trac/ghc/ticket/4837
Excerpts from Mikhail Glushenkov's message of Mon Sep 09 14:15:54 -0700
2013:
Hi,
On Mon, Sep 9, 2013 at 10:11 PM, Simon Marlow marlo...@gmail.com
On 11/09/13 17:28, Duncan Coutts wrote:
All,
I was discussing this with Yuri earlier and I had an idea that I think
may resolve our problems.
Firstly, what are the problems:
1. ghc devs and users grumble because the ghc library depends on
Cabal, making it hard to use the ghc
This is slightly problematic. What if we have a wonderful SIMD-enabled
vector library that we compile with -fllvm, and then use it in a program
that isn't compiled with -fllvm, and some of the wonderful SIMD-enabled
functions get inlined? Presumably we get a panic in the NCG.
Did we discuss
On 12/09/13 20:28, Nicolas Frisby wrote:
On my laptop, a program showed a consistent slowdown with -fdicts-strict
I didn't find any obvious causes in the Core differences, so I turned to
Intel's Performance Counter Monitor for measurements. After trying a few
counters, I eventuall saw that
On 17/09/13 17:28, Edward Z. Yang wrote:
This would be the failing linker_unload test; known problem. Simon Marlow
is working on it.
Simon Marlow is not *actually* working on it at this very minute, and
might not get to it for a few days (I'll probably fix it at ICFP next
week
still fails, it's no worse than failing to compile the
module with the sorry error.
Simon
Geoff
On 09/18/2013 02:54 PM, Simon Marlow wrote:
This is slightly problematic. What if we have a wonderful
SIMD-enabled vector library that we compile with -fllvm, and then use
it in a program
Hey Geoff,
Sorry for not getting around to reviewing this. I just skimmed the
patches and didn't spot anything obviously bogus.
Regarding the sorry errors, are primops the only place that we need to
check? Is it possible that the user might try to call a function that
takes a SIMD
Is it failing on Windows only? It could be an issue with the
granularity of timestamps. I think we use more accurate timestamps on
Linux nowadays, whereas Windows is still using 1 second granularity. If
that's the case, it probably needs a sleep 1 somewhere. If the sleep
1 didn't help,
Could we install this plugin in the Trac please?
http://trac-hacks.org/wiki/DefaultCcPlugin
This will mean that I can be automatically added to the CC list of any
ticket where the component is set to Runtime System, for example.
Cheers,
Simon
Can we stop Trac from sending an email when someone adds themselves to
the CC list of a ticket, without making any other changes to the ticket?
It's hard to filter these automatically.
Cheers,
Simon
___
ghc-devs mailing list
It's typical for benchmarks that allocate a large data structure to spend a
lot of time in the GC. The data gets copied twice - once in the young
generation and then again when promoted to the old generation. You can
make this kind of benchmark much faster by just using a bigger allocation
area.
My validate has a few perf failures (below). Now I know that sampling heap
size is inaccurate, but the evidence here is pretty strong. Also validate
fell over completely in my 2GB VM when Haddock ran out of memory, I had to
give it more memory to complete. Something has got worse recently - this
1 - 100 of 470 matches
Mail list logo
