They're symlinked together, so there's no difference.
Excerpts from Simon Peyton-Jones's message of Fri Mar 01 09:49:24 -0800 2013:
On the path through todays pain I ended up looking at lots of git config
files. I thought the libraries were in http://darcs.haskell.org/packages,
but they
Ever wanted to write this?
-- | Forks a thread, but kills it if it has more than 'limit'
-- bytes resident on the heap.
forkIOWithSpaceLimit :: IO () - {- limit -} Int - IO ThreadId
I have a proposal (and some unpublished experimental patches) which do
just that. Check it out at:
Excerpts from Alexander Kjeldaas's message of Fri Mar 08 01:09:27 -0800 2013:
The API has ccsDynamic, while the example uses newCostCentreStack.
Oops, fixed. (Added the newCostCentreStack helper function).
Would it be possible to attach a listener to GC-events and dynamically
adjust the
Excerpts from Alexander Kjeldaas's message of Fri Mar 08 01:32:50 -0800 2013:
Regarding timely, can this be exploited by a Safe Haskell tenant to
obstruct invocation of the listener to exceed resource limits? Are there
any guarantees that can be given?
With the current scheduler
Excerpts from Andrew Adams-Moran's message of Fri Mar 08 07:01:29 -0800 2013:
This would correspond to the ability to freeze Haskell threads in
mid-execution; no MVar blocking necessary. This is not possible with
the current RTS. I don't know how hard it would be to do.
We have a way to
TICKY_TICKY is the right #def to check, and it should work the straightforward
way. Why doesn't
#ifdef TICKY_TICKY
#define MYBUMP(ctr,n) ctr = ctr + n
#else
#define MYBUMP(ctr,n) /* nothing */
#endif
work?
As a trick, you can check and make sure TICKY_TICKY is actually defined by
inserting an
, but perhaps someone should take a look at this, because I
doubt I'm the only one who would have the problem.
Thanks, Edward!
Richard
On Mar 26, 2013, at 10:48 PM, Edward Z. Yang ezy...@mit.edu wrote:
I bet if you run ghc-pkg check it will say that base is broken due
to a missing librts
Go ahead and open a ticket for this.
Excerpts from Sergei Trofimovich's message of Sat Mar 23 23:36:49 -0700 2013:
Hi guys!
Today I've tried to write a minimal [1] test case for ghc on ia64
(it SIGSEGVs there).
The test case consists of a .cmm and some .hs modues.
I tried to build them
Pushed, thanks.
Edward
Excerpts from Michal Terepeta's message of Tue Apr 16 08:25:01 -0700 2013:
Hi,
Apparently GCC 4.8 has some new warnings that caught a typo in a memset
call in libraries/base/cbits/md5.c. Patch attached.
Cheers,
Michal
From
In your ticket, you mention this patch introduces a race condition. One
possible fix is to have addCFinalizerToWeak# check if the pointer is already
dead, and just run the finalizer immediately if it is. I think this
preserves the semantics, but this needs to be checked closely.
Edward
Reboxing would involve a two-word heap allocation. I guess it is not possible
to argue that this cost would be amortized somewhere else, so you're right.
Edward
Excerpts from Johan Tibell's message of Thu Apr 25 16:01:49 -0700 2013:
On Thu, Apr 25, 2013 at 1:41 PM, Edward Z. Yang ezy
Austin brings up an interesting point, which is that the last time
we had a security vulnerability situation was when it was discovered
that CGI scripts could pass +RTS options to Haskell programs and
get programs to do things that they shouldn't. And, AFAICT, we haven't
ever had any CVEs issued
Excerpts from Ian Lynagh's message of Fri May 17 13:19:00 -0700 2013:
Why not put it on
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/STM
? If you sign up for an account on the trac then you should be able to
edit that page.
Agreed! Please put it on the wiki.
Thanks,
Edward
Is anyone else seeing this? It seems to just be rejecting my SSH key.
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
I think the new box may be missing some software; the pre-commit hooks
are persistently failing.
Excerpts from Ian Lynagh's message of Sat Jul 13 08:22:06 -0700 2013:
On Sat, Jul 13, 2013 at 05:14:59PM +0200, Gabor Greif wrote:
On 7/13/13, Ian Lynagh i...@well-typed.com wrote:
SSH will
I also kicked the GitHub mirroring (manually ran the command so the
server key was added to the cache) so it should be working
again too.
Excerpts from Edward Z. Yang's message of Sun Jul 14 14:33:41 -0700 2013:
OK, I patched it over by changing the shebang line to bash.
I'll need someone to
Hey Ian, can you fix the permissions on /srv/darcs/testsuite.git?
Group needs the write bit. (chmod -R g+w /srv/darcs/testsuite.git)
Edward
Excerpts from Ian Lynagh's message of Sat Jul 13 08:22:06 -0700 2013:
On Sat, Jul 13, 2013 at 05:14:59PM +0200, Gabor Greif wrote:
On 7/13/13, Ian
I want to note something, which is that if we did link in
cas/store_load_barrier, then your lockfree queue would always be
synchronized, even if you didn't compile with -threaded. Perhaps this
is not a big deal, but it is generally nice to not pay the cost of
synchronization when it is
Hey guys,
I recently built a profiled GHC and noticed it was segfaulting.
Has anyone else built a profiled GHC recently?
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hello Jan,
Re (1), there is an important invariant that your transformations should
uphold to avoid infinite loops. This invariant is described in the
Hoopl paper:
• The lattice must have no infinite ascending chains; that is,
every sequence of calls to fact_join must eventually return
Excerpts from Patrick Palka's message of Fri Jul 26 14:21:11 -0700 2013:
Looks like whitehole_spin is _not_ always 0. Contention just seems to be
really rare.
I think the paper Parallel Generational-Copying Garbage Collection with
a Block-Structured Heap can give some intuition on why
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 debugging tool in form
of Fuel would
OK, I ticket-ified this conversation, at some point I'll get around
to this.
Excerpts from Ian Lynagh's message of Sun Jul 21 03:25:50 -0700 2013:
On Sat, Jul 20, 2013 at 11:26:10AM -0700, Edward Z. Yang wrote:
These tests have been doing better than expected in the nightlies
for some while
What happens when you put a loop in your code?
Edward
Excerpts from Jan Stolarek's message of Tue Jul 30 08:34:44 -0700 2013:
I'll allow myself to ask my second question again:
2) In my algorithm I need to initialize all of the blocks in a graph with
bottom element of a lattice, except for
Hey Geoffrey,
The nightly builds are running on your box, correct? How
hard would it be to modify the nightly scripts so that
they also output machine-readable information about the build?
For example, we could then setup a fingerprint database, where
given some revision of head, you could find
Hello Omer,
It is almost certainly the case that the implementation of these
functions should not be the constant return True function. Furthermore,
the implementation should probably be done using:
http://ghc.haskell.org/trac/ghc/ticket/2431
Edward
Excerpts from Ömer Sinan Ağacan's
Hello all,
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 with interesting features.
In
Hi David,
I was initially thinking of something like getopt_long_only, as per:
http://linux.die.net/man/3/getopt_long
however it looks like the portability of that function isn't the greatest,
and from looking at rts/RtsFlags.c:procRtsOpts(...) it might not be the
best solution.
That's
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 resource limits (think BiBoP for cost
Forgive me for asking the classic question: What are you really trying to do?
Edward
Excerpts from Simon Marlow's message of Tue Aug 13 09:25:51 -0400 2013:
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
What happened to the libraries repositories?
ezyang@javelin:~/Dev/ghc-clean/libraries/binary$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote
That's right, 'Any' exists at the type level but the rules by which
locked or unlocked evacuation are based off of closure type. The
relevant code is in rts/sm/Evac.c: look at copy_tag versus copy_tag_nolock.
Unlocked copy is only done for a small number of closure types, although
they do
GHC already has -fwarn-tabs; we could have -fwarn-trailing-whitespace
and turn it on by default, so that validate errors on it but you also
notice it when you're doing a build (if you're paying attention to
warnings).
Edward
Excerpts from Simon Marlow's message of Thu Aug 22 05:04:50 -0700 2013:
My guess is the printf's need to be replaced with swprintf's.
Edward
Excerpts from Simon Peyton-Jones's message of Wed Aug 28 01:25:26 -0700 2013:
OK, so now my windows build is getting further, but it now falls over here.
This one looks more straightforward! Can anyone help?
Simon
Perf builds of GHC also use -O2 for ghc-stage2, so check out what happens
to GHC itself with late demand analysis.
Edward
Excerpts from Nicolas Frisby's message of Fri Aug 30 10:28:24 -0700 2013:
TO: Performance czars and devs
I pushed a patch yesterday enabling a second demand analysis at
Yes, this one is failing for me too. Probably related to the
recent object unload patch for http://ghc.haskell.org/trac/ghc/ticket/8039
Excerpts from Ryan Newton's message of Fri Aug 30 21:51:24 -0700 2013:
That test builds an executable named 'linker_unload' which segfaults for
me. Valgrind
We now build GHC with dynamic linking by default, but I
recently attempted a build with static linking instead. Using:
DYNAMIC_GHC_PROGRAMS=NO
GhcDebugged=YES
I got:
inplace/bin/ghc-stage2 -hisuf hi -osuf o -hcsuf hc -static -H64m -O -fasm
-package-name vector-0.9.1 -hide-all-packages -i
However, as far as I can tell, it is not 100% reproduceable.
In a recent validate of 5f98d44d8617756971cf47c040f2556de4e98f63,
this test does not fail.
Edward
Excerpts from Edward Z. Yang's message of Fri Aug 30 21:55:29 -0700 2013:
Yes, this one is failing for me too. Probably related to the
I'm afraid this doesn't work, since OPTIONS_GHC flags are *pre*pended to
the given options, and therefore overwritten by stuff like -Wall.
This can't be right, because we definitely have used OPTIONS_GHC to add
some -fno-warn-* options in the past (just do a quick grep). Have you
tried it?
Excerpts from David Luposchainsky's message of Tue Sep 03 07:40:38 -0700 2013:
I don't see any documentation.
In what sense? More comments, longer function headers? I thought the
names used were clear, with comments giving an overview over longer
sections. (If you're talking about Haddock:
));
#else
debugBelch(Checking whether to unload %s\n, oc-fileName));
#endif
But that seems deeply unsatisfactory doesn't it?
If not that, then what?
Simon
| -Original Message-
| From: Edward Z. Yang [mailto:ezy...@mit.edu]
| Sent: 28 August 2013 20:59
| To: Simon Peyton
:03 -0700 2013:
From: Simon Peyton-Jones simo...@microsoft.com
To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
marlo...@gmail.com
Cc: ghc-devs@haskell.org ghc-devs@haskell.org
Subject: RE: More windows woe
Message-ID:
59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308
] On Behalf Of Edward
| Z. Yang
| Sent: 04 September 2013 10:15
| To: Jost Berthold
| Cc: ghc-devs
| Subject: Re: RE: More windows woe
|
| I think this is reasonable, with the added caveat that
| the macros should be placed in includes/rts/Linker.h, because that is
| where pathchar is defined. So
debugBelch(Checking whether to unload %S\n, oc-fileName));
#else
debugBelch(Checking whether to unload %s\n, oc-fileName));
#endif
But that seems deeply unsatisfactory doesn't it?
If not that, then what?
Simon
| -Original Message-
| From: Edward Z. Yang [mailto:ezy
));
#else
debugBelch(Checking whether to unload %s\n, oc-fileName));
#endif
But that seems deeply unsatisfactory doesn't it?
If not that, then what?
Simon
| -Original Message-
| From: Edward Z. Yang [mailto:ezy...@mit.edu]
| Sent: 28 August
I've gotten GHC to build on Windows, but the test suite is finicky. Here
is an error I am getting:
= T5267(normal) 50 of 3724 [0, 0, 0]
cd ./arrows/should_compile
'c:/Users/ezyang/Dev/ghc-validate/bindisttest/install
-typed.com
Date: Sun Feb 17 20:25:10 2013 +
Follow unix's version bump
Additionally, I have one more patch for the Windows build, attached below:
commit 80f2fafe39cbc86205afb2eac8d4f60a1ce2684e
Author: Edward Z. Yang ezy...@mit.edu
Date: Wed Sep 4 17:45:37 2013 -0700
Avoid Handler
I manually removed the tee from the validate script, and sallied on.
Here's the next error.
= cabal01(normal) 81 of 3724 [0, 0, 0]
cd ./cabal/cabal01 $MAKE -s --no-print-directory cabal01
VANILLA=--enable-library-vanilla PR
OF=--disable-library-profiling DYN=--enable-shared CLEANUP=1
A lot of failures:
Unexpected results from:
TEST=T5313 registry001 cabal01 dynamicToo002 dynHelloWorld T1969 T5030 T3294
T7797 T7850 haddock.Cabal haddock.compiler haddock.base linker_unload derefnull
T4850 divbyzero T8172 ghci058 prog002 prog003 ImpSafeOnly08 safePkg01
ImpSafeOnly02
Hey folks,
I noticed that profiling has started segfaulting again in
HEAD. Anyone recently push something that might be triggering
this?
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hey folks,
I'm writing a test for #5435 but I don't really know how to structure it
properly. I have a C file and an HS file, and I'd like to run the test
twice: once dynamic (so the C should be compiled with -fPIC) and once
not. Furthermore, I'd like both ways to run when doing 'make fast'
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 is a bug in the build system. When I
Hello Mikhail,
It is a known issue that Template Haskell does not work with profiling (because
GHCi and profiling do not work together, and TH uses GHCi's linker). [1]
Actually,
with the new linker patches that are landing soon we are not too far off from
having this work.
Edward
[1]
Hey Luke,
Please file a bug. Add static001 as a failing test case which is
producing these errors.
Thanks,
Edward
Excerpts from Luke Iannini's message of Thu Sep 05 18:40:14 -0700 2013:
Hi all,
I'm trying to track down the last warnings in GHC iOS.
We get this waterfall of warnings
of Mon Sep 09 16:15:45 -0700 2013:
That sounds terrible expensive to do on every `cabal build` and its a
cost most users won't understand (what was broken before?).
On Mon, Sep 9, 2013 at 4:06 PM, Edward Z. Yang ezy...@mit.edu wrote:
If I am building some Haskell executable using 'cabal
Yep, the linker_unload and T5435_v are known (tracking #5435)
and I'll be fixing them today.
Edward
Excerpts from Jan Stolarek's message of Mon Sep 16 08:28:05 -0700 2013:
I'm getting these validation failures today on HEAD (64 bit Linux):
OVERALL SUMMARY for test run started at Mon Sep 16
That's to be expected, because unfortunately, profiling is not
a transparent operation; you have to compile things differently
and certain features don't work.
You might have better luck doing a slow test run, with WAY=prof
(there are actually a number of other cases too, such as prof_hc_hb,
etc,
My fault, I didn't validate before pushing a comment change.
thanks for catching.
Edward
Excerpts from Simon Peyton-Jones's message of Tue Oct 08 06:04:09 -0700 2013:
I'm getting the error below. I'm fixing it by changing the backslash to a
vertical bar. It's in a comment so I guess that's
Hey Gergeley,
(obviously we would have to call mpz_free here and there, but that
seems doable).
Actually, this is precisely the problem. When is a GMP integer freed?
It can have pointers to it from objects on the heap, so this free should
only occur when the integer is dead, with no
So that leads me to wonder: are there limitations that we should be
aware of? Have I simply been lucky so far?
If you are loading Haskell code, you will need to be very careful to
make sure you load all of the dependencies as well. There are a number
of plugins packages and a paper:
It's strong. How to tell: x86 doesn't support really have any kind of
weak CAS implementation; and our PowerPC implementation loops over
LL/SC. (oh, and our asm is marked volatile)
As for whether or not there are any uses of CAS that don't need these
guarantees, probably the best way to figure
Hello Johan,
Off the top of my head:
Technically speaking, the compiler does not have to be optimized to do
build tests; just the libraries. So you could probably make the builds
run a bit faster this way.
Your command for nofib will only run the standard benchmarks;
to run, for example, the
Hello all,
I've created a GHC team on Launchpad to manage the code imports and
build recipes https://launchpad.net/~ghc Why? I recently was playing
around with Launchpad's build recipes service, and realized that this
could be another helpful source of builds for GHC (resulting in proper
Ubuntu
Is the Akismet filter enabled? In my experience, combining it with
a technique like NoSpamNX (some sort of honey-pot field which wide
range spambots are susceptible to) lowers spam hits to a level where
manually moderating the rest is fine. If it is too hard for
contributors to mark entries as
Did the spamchecker get turned off? I just deleted a ticket (#8982;
check your mail archives) which should have been caught by essentially
any spamchecker worth its salt.
Also, do we have any facilities for permanently banning spammers?
Excerpts from Kyle Van Berendonck's message of 2014-04-07
I've got perf failures on Linux 64-bit on ghc-7.8 (and master too, I
think). Please take a look.
Unexpected results from:
TEST=T4801 T3064 T5837 T6048
OVERALL SUMMARY for test run started at Thu Apr 10 15:33:27 2014 PDT
0:02:52 spent to go through
3920 total tests, which gave rise to
Judging from affect files, probably
commit c269b7e85524f4a8be3cd0f00e107207ab9197af
Author: Dr. ERDI Gergo ge...@erdi.hu
Date: Thu Apr 10 22:13:00 2014 +0800
Split off pattern synonym definition checking from pattern inversion
Edward
Excerpts from Joachim Breitner's message of 2014-04-11
Hey Gergo,
It looks like this failure came from one of your commits, which didn't
include a submodule update.
One trick that I find very useful for making sure that I haven't missed
any files when submitting a patch is to always run 'git status' before I
push, and carefully look at all the
Hey Simon,
If you have no Haddock changes, try cd'ing into the haddock directory
and doing a hard reset to the remote origin (so something like
git reset --hard origin/master *INSIDE HADDOCK*), and then changing
back to the main directory and git add'ing the directory.
Edward
Excerpts from
Hey Johan,
Superficial comments for now. Are you planning on supporting word
variants?
Callish mach-ops, as generated from primops, are not sunk across,
but this behavior today is accidental (see Note [Foreign calls clobber
heap]), so be sure to adjust the notes.
Edward
Excerpts from Johan
Hello Luite,
GHC's separation of weak references into keys and values is a
generalization which can be useful to avoid space leaks; the motivation
for the design is described in Stretching the storage manager: weak
pointers and stable names in Haskell.
In particular, the variant of weak
Excerpts from Luite Stegeman's message of 2014-05-23 17:11:30 -0700:
Actually it's not the same, since I think the finalizer should still be run
if the weak pointer object is unreachable (and it should run when the key
becomes unreachable).
I think that's a legitimate point in the design
Yes, this should be easy to fix, it just hasn't been done.
Edward
Excerpts from Carter Schonwald's message of 2014-05-28 11:21:30 -0700:
@Edwardk, ezyang has a ticket on this very topic!
https://ghc.haskell.org/trac/ghc/ticket/9075
(is that what you're thinking?)
On Wed, May 28, 2014 at
Hey Ömer,
As a first guess, there were a few known segfaults fixed in the ghc-7.8
branch. Have you tried building GHCJS using this branch? Could be one
of these three:
https://ghc.haskell.org/trac/ghc/ticket/9001
https://ghc.haskell.org/trac/ghc/ticket/9045
Currently, most GHC API tests are not run on 'make fast',
ostensibly because linking against the GHC API can take a while.
I propose that change this, and run GHC API tests by default.
Reasons:
1. The GHC API is closely tied a lot of internal structure of GHC, so
it's very easy to make a change,
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
pushCostCentre is called with NULL ccs, but we only create these
invocations in code generation and
Yes, I think all NoCCS are removed in the SCCfinal pass. NoCCS
is a convenient thing to fill in when STG is initially created.
Edward
Excerpts from Ömer Sinan Ağacan's message of 2014-06-05 09:59:36 -0700:
Hi all,
Can a StgRhs have `NoCCS` as cost-centre stack when -prof is provided
while
As long as you check the performance impact on 32-bit, sounds good to
me.
Edward
Excerpts from Herbert Valerio Riedel's message of 2014-06-21 11:09:44 +0100:
Hello Simon (et al.),
While doing #9224[1] as a finger-exercise to extend the lexer to support
base-2 integer literals, I got stuck
I wonder if we should have some magic variable in the build system
that induces a full rebuild, so if you push a patch which requires
a rebuild you can bump the variable and let it know.
Edward
Excerpts from Carter Schonwald's message of 2014-07-03 17:20:44 +0100:
yay! :)
(i spent quite a bit
Excerpts from Jan Stolarek's message of 2014-07-17 08:35:19 +0100:
1. Complaining about any untracked or uncommited changes in the source tree.
This is mostly
annoying. How can I tell arcanist to ignore such changes? Rant: I really
don't like tools that
try to be smarter than me and
The reason for this is that the builders do not have a sufficiently
recent version of process, which Cabal has upgraded to depend on.
Probably 'cabal update cabal install process' should bring it up to
date and make it working. Unfortunately, the build system bypasses
Cabal for the bootstrap
Hello Karel,
You should blow away your copy (well, preserve the patches), upgrade
your version of Git and then check out again. You've run into
this bug:
http://comments.gmane.org/gmane.comp.version-control.git/193492
Cheers,
Edward
Excerpts from Karel Gardas's message of 2014-07-20
Since this patch causes GHC HEAD to not bootstrap out of the box
from GHC 7.6, I've reverted it for now. We'll have to cross
this bridge sometime though.
Edward
Excerpts from Joachim Breitner's message of 2014-07-20 17:18:56 +0100:
Hi,
Am Sonntag, den 20.07.2014, 17:08 +0100 schrieb Edward
Hello all,
As you may have noticed, I've been knocking around GHC and Cabal the
past few weeks. One of the tasks that has been on my list is
essentially reimplementing Philipp Schuster's 2012 GSoC, with a few
small but important architectural differences. Here is a status report
of what is
Excerpts from Joachim Breitner's message of 2014-07-22 08:23:22 +0100:
[Replying to the list, in case it was sent to me in private by accident]
Oops, thanks.
thanks for the explanations, it makes it clear to me.
Do the package key contain the flags used to compile dependencies? In
the
For the record, Cabal is now up-to-date, we're using a different
patch which relaxes the version constraint on process so that 7.6
bootstraps.
Cheers,
Edward
Excerpts from Joachim Breitner's message of 2014-07-21 08:22:32 +0100:
Hi,
Am Sonntag, den 20.07.2014, 22:57 +0100 schrieb Edward
Right now, GHC has a very complex and hard to explain algorithm for
picking packages from the package database when you give it a pile of
-package/-package-id/-{hide,ignore,trust,distrust}-package flags.
Roughly, it currently does something like this.
1. Concatenate all of the package databases
Excerpts from Edward Z. Yang's message of 2014-07-24 15:57:05 +0100:
- It assumes *-hide-all-packages* at the beginning. This scheme
probably works less well without that: now we need some consistent
view of the database to start with.
Actually, thinking about this, this dovetails nicely
.
On Thu, Jul 24, 2014 at 11:12 PM, Edward Z. Yang ezy...@mit.edu wrote:
Excerpts from Edward Z. Yang's message of 2014-07-24 15:57:05 +0100:
- It assumes *-hide-all-packages* at the beginning. This scheme
probably works less well without that: now we need some consistent
view
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hello Karel,
When your submodules get updated, you need to add them to your commit
(since the parent repository maintains pointers to the submodules).
Then they will no longer show up as dirty and you can submit the
Phabricator patch.
Edward
Excerpts from Karel Gardas's message of 2014-07-25
Hello all,
Since we're relaxing the constraint that a package ID correspond to
exactly one installed package in the package database, it will now
sometimes be necessary to query the package database using ghc-pkg
for a specific installed package ID. At the moment, none of the
commands support
it points to currently
non-existing patches (in public libraries/unix + primitive). Am I right
that this works in this way?
Thanks,
Karel
On 07/26/14 09:39 PM, Edward Z. Yang wrote:
Hello Karel,
When your submodules get updated, you need to add them to your commit
(since
Excerpts from Simon Peyton Jones's message of 2014-07-28 07:45:23 +0100:
Great stuff. Is this documented somewhere, notably in
http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html
for GHC, and somewhere in Cabal?
You're right, I should add a line to the installed package
Excerpts from Edward Z. Yang's message of 2014-07-28 11:38:43 +0100:
You're right, I should add a line to the installed package
specification. We're already documented as far as Cabal is concerned.
OK, this is done.
___
ghc-devs mailing list
My 2 cents: I don't really care what we do, as long as (1) it's obvious
where to put new gitignore entries, and (2) the gitignore list is
accurate. Perhaps the testsuite should learn about Git and offer to
add the files it creates to gitignore?
Cheers,
Edward
Excerpts from Herbert Valerio
Recalling when I implemented this functionality, I think not
interrupting threads in the exit sequence was just an oversight,
and I think we could implement it. Seems reasonable to me.
Edward
Excerpts from Andreas Voellmy's message of 2014-07-30 23:49:24 +0100:
Hi GHCers,
I've been looking
We need to rethink the shadowing behaviour. It is designed to handle
the case where we have the same PackageId (name + version) in two
different DBs (e.g. global and local). Shadowing takes the topmost one
of these (e.g. local, or rightmost -package-db flag). We can relax this
CC'd Simon because you were touching these test-cases recently.
You'll need to run with -DDEBUG, which is probably why validate didn't
catch these. Maybe the ASSERT is out of date?
= ghci044(ghci) 1719 of 4065 [0, 0, 0]
[72/1822]
cd
Yes, on my box, this test is now failing (because the stat is too good):
Expectedhaddock.base(normal) max_bytes_used: 127954488 +/-10%
Lower bound haddock.base(normal) max_bytes_used: 115159039
Upper bound haddock.base(normal) max_bytes_used: 140749937
Actual
1 - 100 of 324 matches
Mail list logo
