thing,
there seems to be several cases where it's used to represent a negative
offset.
On Thu, Aug 7, 2014 at 3:53 PM, Johan Tibell johan.tib...@gmail.com wrote:
I guess this example, from mk_switch in StgCmmUtils, is the same
return (mkSwitch (cmmOffset dflags tag_expr (- real_lo_tag)) arms
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 word size.
That sounds like an easier
Despite having the same name, these two are quite different from what
I remember. The GHC.Event one (which me/Bryan added) is just a wrapped
Int, while the Data one is really more of a mutable state thing.
On Sat, Aug 2, 2014 at 8:40 AM, Michael Schröder mc.schroe...@gmail.com wrote:
Is there a
On Thu, Jul 31, 2014 at 6:55 PM, Austin Seipp aus...@well-typed.com wrote:
And also, take note the conditional is very specific; you want
COLLECT_GC_STATS only when NO_GC_STATS is the current setting - if you
unconditionally force COLLECT_GC_STATS, then things like `+RTS
-sstderr -RTS` will no
On Wed, Jul 30, 2014 at 12:46 PM, g...@git.haskell.org wrote:
+ifneq $(ValidateSpeed) FASTEST
+HADDOCK_DOCS= NO
+else
HADDOCK_DOCS= YES
+endif
This conditional looks like it has been reversed.
___
ghc-devs mailing list
On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 30 July 2014 22:07, Andreas Abel andreas.a...@ifi.lmu.de wrote:
I am a bit surprised by the distinction you outline below. This is maybe
because I am native German, not English. The German equivalent of
On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel h...@gnu.org wrote:
On 2014-07-29 at 11:29:45 +0200, Niklas Hambüchen wrote:
instance {-# OVERLAPPABLE #-} Show a = Show [a] where …
Is the syntax somewhat flexible in where the pragma can be placed?
For example, some might prefer
Thanks a lot Simon.
Re top-level bindings:
I agree. There's no good time to force CAFs so they'll need to be
forced on first use.
Re newtypes:
I agree. Pattern matching on newtypes should be strict.
Implementation:
Where do I get started? I think we looked at some code together during
On Thu, Jul 24, 2014 at 11:10 AM, Roman Cheplyaka r...@ro-che.info wrote:
Will case with an irrefutable pattern force the scrutinee, too?
I.e. will
case x of { pat - y }
desugar to
case x of { pat - x `seq` y }
?
Yes. The user has to write ~x if he/she doesn't want that.
Will
Hi!
I started a draft spec for the Strict language pragma we chatted about
during our call a while ago. I made the big mistake of writing it much
after the actual discussion, so I forgot most of the details.
https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
Perhaps if you could ask questions
A patched bindist sounds like a good idea. I've just uploaded
Cabal-1.18.1.4 so you should be good to go.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
PM, Niklas Larsson metanik...@gmail.com wrote:
That's true, I used mingw.
I have created a ticket https://ghc.haskell.org/trac/ghc/ticket/9346#ticket.
2014-07-22 12:22 GMT+02:00 Páli Gábor János pali.ga...@gmail.com:
2014-07-22 11:49 GMT+02:00 Johan Tibell johan.tib...@gmail.com
On Mon, Jul 21, 2014 at 1:30 AM, Nick Smallbone nic...@chalmers.se wrote:
1. We make sure that tf-random becomes stable and hope it can be
included in the next version of the platform.
2. We add a simple TFGen-inspired generator directly to QuickCheck.
3. We fix StdGen by replacing it
to commit
it, I haven't the rights to do it.
Niklas
Från: Simon Peyton Jones
Skickat: 2014-07-18 15:55
Till: Niklas Larsson; Johan Tibell
Kopia: ghc-devs@haskell.org
Ämne: RE: Windows breakage -- again
Thank you all for pursuing this. I gather that you know
A perhaps silly question, *should* ghc-prim be built with i386 or i686?
On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik...@gmail.com wrote:
I just found exactly the same thing! Well, I used i686 instead.
Sounds like it's worthwhile to see if this is limited to ghc-prim or if
there's
of
them appears on the 486.
i686 should be safe, it goes all the way back to Pentium Pro.
2014-07-17 8:33 GMT+02:00 Johan Tibell johan.tib...@gmail.com:
A perhaps silly question, *should* ghc-prim be built with i386 or i686?
On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson metanik
On Thu, Jul 17, 2014 at 8:40 AM, Simon Peyton Jones
simo...@microsoft.com wrote:
| I used to be a 80 column guy, but moved away from that the last years.
| But you are right, there must be an upper limit and, if 80 is a
| problem for code reviews, then it's a reasonable choice.
As laptop
beside the point, if we aren't able to run the code
generated by gcc (in whatever mode) then there's a bug somewhere.
Cheers,
Simon
On 17/07/2014 07:39, Johan Tibell wrote:
Alright, then which Make file do we need to fix to make sure GCC is
called correctly? Also, I remember reading
I added some primops about a month ago
(4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add,
a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual
[1] says:
Not all operations are supported by all target processors. If a
particular operation cannot be
You can rollback the commit (git revert
4ee4ab01c1d97845aecb7707ad2f9a80933e7a49)
and push that to the repo if you wish. I will try to re-add the primop
again after I figure out what's wrong.
On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell johan.tib...@gmail.com
wrote:
I added some primops about
This is great. I wanted this for a long time.
Joachim, could you write a wiki page with step-by-step instructions for how
to set this up, detailed enough that e.g. one of our infrastructure
volunteers could set it up on another machine.
Haskell infrastructure people, do we have a (e.g. Hetzner)
I won't have time to fix this today and I will be out until Tuesday so I
suggest you run
git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49
and push the result to origin/master to unblock yourself (and any other GHC
devs on Windows?)
On Wed, Jul 16, 2014 at 9:56 AM, Johan Tibell johan.tib
We are on x86(-64), but not on other archs. Simon, which arch are you on?
On Wed, Jul 16, 2014 at 5:58 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
Huh. We're not generating the atomics assembly directly ourselves?
On Wednesday, July 16, 2014, Johan Tibell johan.tib...@gmail.com
: Johan Tibell johan.tib...@gmail.com
Skickat: 2014-07-16 09:57
Till: Simon Peyton Jones simo...@microsoft.com
Kopia: ghc-devs@haskell.org
Ämne: Re: Windows breakage -- again
You can rollback the commit (git revert
4ee4ab01c1d97845aecb7707ad2f9a80933e7a49)
and push that to the repo if you
This bug report might shed some light on this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47460
I wonder if I've misunderstood the GCC docs at
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins.
My reading of the docs was that if the platform
On Thu, Jul 17, 2014 at 12:23 AM, Páli Gábor János pali.ga...@gmail.com wrote:
2014-07-16 23:56 GMT+02:00 Johan Tibell johan.tib...@gmail.com:
My reading of the docs was that if the platform doesn't support the needed
instructions then GCC will generated a call to e.g. __sync_fetch_and_add_1
This was discussed earlier. We need to stick with the Cabal that ships with
the GHC version we're using and thus we need to stick with
cabal-install-1.18.
On Tue, Jul 15, 2014 at 9:33 AM, Alois Cochard alois.coch...@gmail.com
wrote:
Why not directly to 1.20.x?
On Jul 15, 2014 7:59 AM, Andres
[mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan
Tibell
*Sent:* 07 July 2014 08:39
*To:* ghc-devs@haskell.org
*Subject:* ANN: New source documentation policy for GHC
Hi all!
After some discussion [1] we've decided to require Haddock comments for
all top-level entities (i.e
I thought clang was slower than gcc because clang doesn't support thread
local variables (in some form we need) and therefore GC performance
suffered a lot on clang.
On Sat, Jul 12, 2014 at 9:27 PM, Mark Lentczner mark.lentcz...@gmail.com
wrote:
In building the OS X bindist for 7.8.3, I had to
This is great!
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Thanks Mark!
Notes on my packages:
* hashable can be bumped to 1.2.2.0.
* network can be bumped to 2.4.2.3
* unordered-containers can be bumped to 0.2.4.0
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi all!
After some discussion [1] we've decided to require Haddock comments for all
top-level entities (i.e. functions, classes, and data types) in new [2] GHC
code. If you're writing new code, please try to add at least a sentence of
two documenting what the function does and why. When you're
On Thu, Jul 3, 2014 at 6:29 PM, Simon Peyton Jones simo...@microsoft.com
wrote:
* Insisting on line comments exclusively, carries a cost. The on-screen
distraction
of line comments, and the nuisance of writing them, is not trivial.
Perhaps it
is bearable, but it's non-zero. See
On Wed, Jul 2, 2014 at 6:04 PM, Austin Seipp aus...@well-typed.com wrote:
Of course, I'd also like it if this rule explicitly extended to
top-level data types, type classes, etc as well. I believe that was
the intention but I'm just making sure. :)
That was the intention.
(Finally, I
I fixed the x86 issue and re-commited my work as
4ee4ab01c1d97845aecb7707ad2f9a80933e7a49.
On Fri, Jun 27, 2014 at 1:27 PM, Simon Marlow marlo...@gmail.com wrote:
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
Richard,
Not requiring contributors to check that the Haddock render well is
OK. As long as the comments are there someone with free time on their
hands can always tidy up the rendering.
I'm looking forward to the day I can browse the GHC Haddocks and make
sense of them. I tried in the past but
Left hold off one more week to give more contributors a change to
voice their thoughts. If no one protests I will announce the new
policy next Monday. Sounds good?
___
ghc-devs mailing list
ghc-devs@haskell.org
On Mon, Jun 30, 2014 at 11:22 PM, Dominick Samperi djsamp...@gmail.com wrote:
Given the examples provided with this proposal it looks like this
change is targeted mostly at compiler hackers, and not at
library/package developers.
Yes, this discussion is only about documenting the GHC modules.
On Fri, Jun 27, 2014 at 12:17 PM, Simon Peyton Jones
simo...@microsoft.com wrote:
I’d be OK with this, (it’s a bit like requiring signatures on all top level
functions) but I don’t know how we’d enforce it.
I think social enforcement is enough. If we agree that this is
something we want to do
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 to arrange to not use the complicated
We could create a branch for 7.8, but I don't know which commit to branch
of. If someone can figure out which cabal 7.8 shipped with we can add the
branch.
On Sat, Jun 28, 2014 at 7:48 AM, Manuel M T Chakravarty
c...@cse.unsw.edu.au wrote:
I noticed that the Cabal package doesn’t have a
Should be fixed in 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177.
On Thu, Jun 26, 2014 at 8:07 AM, Johan Tibell johan.tib...@gmail.com
wrote:
As a very temporary (and wrong) workaround you can edit
libraries/ghc-prim/cbits/atomic.c to have the functions involving nand all
return 0. I should have
d8abf85f8ca176854e9d5d0b12371c4bc402aac3
Author: Johan Tibell johan.tib...@gmail.com
Date: Mon Jun 9 11:43:21 2014 +0200
triggers that issue? I'm not claiming that the commit is actual culprit,
this may be just recently un-hidden issue in linear regs allocator on i386!
Thanks!
Karel
...@haskell.org] On Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two days old build breakage on i386.
|
|
| Hello,
|
| builders running on i386 building for this platform caught issue which
| shows as a build breakage:
|
| ghc-stage1: panic
On Thu, Jun 26, 2014 at 2:31 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:
On 06/26/2014 12:37 PM, Johan Tibell wrote:
I think it's reasonable to say my change triggers the issue, but I don't
know why and I need someone who understand the register allocator better
(e.g. Simon M
unrelated change has broken the
Windows build. (Thanks for Karel, who got to it a day before me.)
Thanks
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two
Herbert pushed my revert for me a minute ago. Everyone should be good once
they sync.
On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell johan.tib...@gmail.com
wrote:
I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I
pushed this morning) which is fine. You should
, Jun 26, 2014 at 3:05 PM, Johan Tibell johan.tib...@gmail.com
wrote:
Herbert pushed my revert for me a minute ago. Everyone should be good once
they sync.
On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell johan.tib...@gmail.com
wrote:
I guess you don't have
at 8:17 PM, Johan Tibell johan.tib...@gmail.com
wrote:
I'm trying to understand the output from the register allocator:
(GHC version 7.9.20140626 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1nD
assignment: [(n1nD
I find the automatic squashing to rather harmful to the commit history. So
if you have several nice commits that you want to send for review, don't
use arc land to commit them, as it will ruin the history. Instead git push
them as per normal and use `arc close` (IIRC) to close the code review. I
---
commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
Author: Johan Tibell johan.tib...@gmail.com
Date: Mon Jun 9 11:43:21 2014 +0200
Add more primops for atomic ops on byte arrays
Summary:
Add more primops for atomic ops on byte arrays
Adds the following primops
worldwide GHC cycles are currently spent on x86. Arm will surely
become more important over time. But what's right for x86 is probably
right for us for the near/medium term.
On Tue, May 20, 2014 at 11:04 AM, Johan Tibell johan.tib...@gmail.com
wrote:
Sequentially consistent also
I would say sooner. Here are still unmerged things that I think we could
merge before (i.e. easy to merge):
https://ghc.haskell.org/trac/ghc/ticket/9001
https://ghc.haskell.org/trac/ghc/ticket/9078
https://ghc.haskell.org/trac/ghc/ticket/8475
https://ghc.haskell.org/trac/ghc/ticket/8783
On Tue, May 27, 2014 at 11:31 AM, Simon Peyton Jones
simo...@microsoft.comwrote:
are these all on Austin’s list, which he sent a pointer to?
Yes, they were in the last section of the page he linked to.
___
ghc-devs mailing list
ghc-devs@haskell.org
Sequentially consistent also corresponds to, according to the LLVM docs:
the C++0x/C1x memory_order_seq_cst, Java volatile, and the gcc-compatible
__sync_* builtins, so we'll be in good company.
On Tue, May 20, 2014 at 5:01 PM, Johan Tibell johan.tib...@gmail.comwrote:
After some discussion
On Fri, May 16, 2014 at 3:33 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.ukwrote:
Is there a reason behind not just detabbing (and removing trailing
whitespace) the whole tree in a patch? If you're going to detab in a
separate patch anyway, might as well do all of it once and for all.
There
On Fri, May 16, 2014 at 3:42 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.ukwrote:
It does not matter I feel because you're encouraged to detab in a
separate patch anyway so blaming will show that whether it's all done at
once or separately.
It's indeed a minor reason. I think the thinking is
I will update the wiki page (and later CmmSink) with the guarantees we
expect CallishMachOps to provide. We do need to pick what kind of guarantee
we want to provide. Options are here:
http://en.cppreference.com/w/cpp/atomic/memory_order
Do we want to have these CallishMachOps to imply a full
Hi all,
I'm not sure how to continue from here. The current backend story feels a
bit shaky. Do we think we accurately need to reflect the memory model in
Cmm before we should venture into this area at all, or are we comfortable
relying on the current implementation of CallishMachOps with the
That would be nice. I had to fix some breakage caused by this in one of
Bryan's libraries.
On Mon, May 12, 2014 at 4:12 PM, Gabor Greif ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
Hi,
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.
-- Johan
___
ghc-devs
On Sun, May 4, 2014 at 5:45 PM, Sergei Trofimovich sly...@gmail.com wrote:
Does it make sense to have 64-bit alloc_limit on 32-bit box?
I think so. You allocate 2^32 bytes pretty quickly.
___
ghc-devs mailing list
ghc-devs@haskell.org
bits on a 32 bit machine, and 64 bit on a
64 bit machine?
On 4 May 2014 16:06, Johan Tibell johan.tib...@gmail.com wrote:
On Sun, May 4, 2014 at 5:45 PM, Sergei Trofimovich sly...@gmail.comwrote:
Does it make sense to have 64-bit alloc_limit on 32-bit box?
I think so. You allocate 2^32 bytes
On Wed, Apr 30, 2014 at 5:22 PM, Adam Gundry a...@well-typed.com wrote:
If possible, I'd prefer to merge the existing patches more or less as
is, then I can work on the library design without continually needing to
fix merge conflicts.
Agreed. We should try to get the patches in sooner
I believe you need to run `git submodule update`. The orf branch was likely
set to use a different commit from the haddock repo than your current repo.
Git doesn't automatically assume that you want to switch your submodule to
use the same commit as the orf branch was using, hence you now have a
On Thu, Apr 24, 2014 at 12:38 PM, Simon Peyton Jones
simo...@microsoft.comwrote:
That seems a bit extreme. I thought switching branches is precisely what
git is good at.
It was made not so great in the past (i.e. 7.8) by us having the homegrown
sync-all pull system instead of submodules.
On Fri, Apr 18, 2014 at 8:12 AM, Michał J Gajda mjga...@gmail.com wrote:
Dear Friends,
I have a few weeks free just now, and a keen interest in GHC performance,
so please count me in as a person interested in developing the solution :-).
On Thu, Apr 10, 2014 at 5:57 PM, Johan Tibell
On Fri, Apr 18, 2014 at 12:20 PM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
This sounds as if you'd want to file an issue and/or pull-request ASAP
for Cabal 1.20 before it gets released;
Just fixed this on the 1.20 branch:
Fixed on the Cabal 1.20 branch:
https://github.com/haskell/cabal/commit/8af39a5f827dcf5b5ca68badc2955e4cccbb039d
I suggest we update the submodule to use that.
___
ghc-devs mailing list
ghc-devs@haskell.org
On Fri, Apr 11, 2014 at 10:58 AM, Simon Marlow 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
regressions. When we have a +/- 10% window, someone can commit a 9%
On Thu, Apr 10, 2014 at 3:55 PM, Austin Seipp aus...@well-typed.com wrote:
I don't necessarily propose we put it in the GHC repository (the LLVM
folks do this, but I think it would make actually *updating* the
website somewhat confusing), just somewhere more public. Does anyone
have any
On Thu, Apr 10, 2014 at 4:00 PM, Austin Seipp aus...@well-typed.com wrote:
I thought that too, but the reason I suggest GitHub is because it
might make people more inclined to submit patches. I still hear people
who want the GitHub mirrors to allow pull requests, but I think moving
it to the
Hi!
Bumping the major version number of base creates a bunch of work for
package maintainers. Some times this work is justified, when there were
actual non-backwards compatible API changes and maintainers need to fix
their code. Often the work is busy work, as there were no real breakages
and
I just noticed that 7.8.1 bumps the major version of base, but I can't see
any breaking changes in the release notes:
http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/release-7-8-1.html
On Wed, Apr 9, 2014 at 12:00 PM, Johan Tibell johan.tib...@gmail.comwrote:
Hi!
Bumping the major
On Wed, Apr 9, 2014 at 2:17 PM, Herbert Valerio Riedel
hvrie...@gmail.comwrote:
On 2014-04-09 at 12:00:36 +0200, Johan Tibell wrote:
*Short term*
- Make sure we only bump the major version number when we actually
make
a breaking change. We don't need to bump base because the major
I'll mirror what Joachim said: just get something working. Having an email
sent to ghc-devs@ every time something breaks (and getting down false
positives here is very important) is already a huge win, no matter what
kind of build system sits behind that email.
On Tue, Apr 8, 2014 at 3:28 PM, Austin Seipp aus...@well-typed.com wrote:
Hello all,
The source distribution is now available:
http://www.haskell.org/ghc/dist/7.8.1/
Feel free to make builds - I'll add them as they come in and will
announce soon...
Thanks for all your hard work Austin.
I don't have a 32-bit machine to test on, but I thought I set the
InlineByteArrayAlloc test to only run on 64-bit. Feel free to set the
expected value on 32-bit to whatever you're getting.
On Sun, Apr 6, 2014 at 11:49 AM, Simon Peyton Jones
simo...@microsoft.comwrote:
Several perf tests have
definitely not be
related.
On Sun, Apr 6, 2014 at 1:22 PM, Johan Tibell johan.tib...@gmail.com wrote:
I don't have a 32-bit machine to test on, but I thought I set the
InlineByteArrayAlloc test to only run on 64-bit. Feel free to set the
expected value on 32-bit to whatever you're getting
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Should be fixed by 838bfb2. Sorry about the breakage.
On Sat, Mar 29, 2014 at 10:53 AM, Johan Tibell johan.tib...@gmail.comwrote:
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Let me take a second look. The code validates on OS X so I'm fixing a bit
blind here.
On Sat, Mar 29, 2014 at 5:11 PM, Joachim Breitner
m...@joachim-breitner.dewrote:
Hi Johan,
back from a holiday, so time to report CI failures...
Am Samstag, den 29.03.2014, 11:36 +0100 schrieb Johan
I'm validating a fix.
On Sat, Mar 29, 2014 at 5:15 PM, Johan Tibell johan.tib...@gmail.comwrote:
Let me take a second look. The code validates on OS X so I'm fixing a bit
blind here.
On Sat, Mar 29, 2014 at 5:11 PM, Joachim Breitner
m...@joachim-breitner.de wrote:
Hi Johan,
back from
I fixed some more missing symbols. If this doesn't do it I'll have to
reproduce it on a Linux machine tomorrow and fix it there.
On Sat, Mar 29, 2014 at 5:23 PM, Johan Tibell johan.tib...@gmail.comwrote:
I'm validating a fix.
On Sat, Mar 29, 2014 at 5:15 PM, Johan Tibell johan.tib
What's the right way to fix libraries (e.g. aeson) that break because
classP was removed?
On Mon, Feb 10, 2014 at 2:39 AM, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/template-haskell
On branch : master
Link :
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 some_file
git add some_file
git commit -m Commit to base repo
git push # push
On Mon, Mar 17, 2014 at 2:45 PM, Simon Peyton Jones
simo...@microsoft.comwrote:
| The one interesting case is T4306 which fails because the generated name
| $wupd is regarded as an infix name, and thus with my new code is
| rendered as
|
|($wupd) :: GHC.Prim.Double# - GHC.Prim.Double#
|
, rather than just the first one.
Simon
*From:* Johan Tibell [mailto:johan.tib...@gmail.com]
*Sent:* 17 March 2014 14:00
*To:* Simon Peyton Jones
*Cc:* Dr. ERDI Gergo; GHC Devs
*Subject:* Re: -ddump-types vs -fprint-explicit-foralls, and symbol-ness
of worker/wrapper names [Re: [commit
I just had reason to have a look at this code. I just want to say thanks
for writing such nice, readable code. I wish all code in GHC had nicely
written Haddock like these. Would make GHC hacking a bit more approachable.
On Tue, Aug 27, 2013 at 4:11 PM, g...@git.haskell.org wrote:
Repository :
) the cpp that actually gets called during the
build is 'gcc -E', which is clang.
On Thu, Mar 13, 2014 at 10:03 AM, Johan Tibell johan.tib...@gmail.comwrote:
Checking out a clean tree today (commit: ) I can no longer build HEAD.
Here's what I did:
git clone git://git.haskell.org/ghc.git
cd ghc
Hi,
Did something change in pretty-printing recently? I saw these new validate
failures today:
Unexpected failures:
ghci.debugger/scripts break008 [bad stdout] (ghci)
ghci.debugger/scripts break012 [bad stdout] (ghci)
ghci.debugger/scripts break026 [bad stdout] (ghci)
Could these changes be related to the validate failures I just posted about
on the mailing list?
On Thu, Mar 13, 2014 at 2:21 PM, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
Hi all,
After some refactoring of the StgCmmPrim, it's now possible to have both an
inline and an out-of-line (in PrimOps.cmm) version of the same primop. Very
soon (#8876) we'll have both an inline and an out-of-line version of
newByteArray#. The inline version is used when the array size is
On Thu, Mar 13, 2014 at 10:24 PM, Simon Marlow marlo...@gmail.com wrote:
It's a bad idea for large arrays (= 3k), because when allocated via
allocate() these arrays get a blocked marked with BF_LARGE that doesn't get
copied during GC.
It might be a good idea for arrays less than this size
On Thu, Mar 13, 2014 at 10:42 PM, Simon Marlow marlo...@gmail.com wrote:
Oh I see, sorry for misunderstanding. In that case it's a straightforward
code size / speed tradeoff. When a similar case came up recently (PAP
optimisations) I turned it on for -O2 only. Someday I'd really like to
Hi,
I get the following warning every time I push to git.haskell.org. Anyone
have an idea what the correct fix is?
$ git push origin master
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = UTF-8,
LANG =
On Sun, Mar 9, 2014 at 10:22 PM, Jan Stolarek jan.stola...@p.lodz.plwrote:
useless basic blocks that haven't been optimized away. Is this to be
expected?
I believe this should not happen but it's hard to say without looking at a
complete dump. Could
you post full Cmm dump + a minimial
Hi,
For MutableArray#s, a card is supposed to be marked if the array is
pointing to an object in a younger generation than itself resides in. Since
the array always points to elements in the same or an older generation when
it gets allocated, we should be fine with marking the array as clean upon
On 08/03/2014 07:45, Johan Tibell wrote:
Hi,
In my mind the quick build should be like the perf build, except
building the stage2 compiler should be much faster. However, the perf
build uses
GhcLibHcOpts = -O2
while the quick build uses
GhcLibHcOpts = -O -fasm
While looking at some generated Cmm I saw things like this
c1Cm:
goto c1Cq;
c1Cq:
i.e. useless basic blocks that haven't been optimized away. Is this to be
expected?
-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
101 - 200 of 298 matches
Mail list logo
