Dnia środa, 16 stycznia 2013, Ian Lynagh napisał:
I assume you can reproduce this by running
/usr/bin/dblatex -P 'filename.as.url=0'
docs/users_guide/users_guide.xml --ps -o docs/users_guide/users_guide.ps
Running this command in the GHC build tree gives me:
Build the listings...
warning:
Dnia czwartek, 17 stycznia 2013, Simon Peyton-Jones napisał:
But if you find files that are stable -- have not been modified for some
months -- then yes you could detab them.
This seems to be a good heuristic.
I'm unsure it's worth the bother
Cleaner code is worth the bother :) Especially
I don't think it's worth the bother either: conflicts are a pain and
slow down development, whereas tabs don't. (...) there certainly are a
few active branches with large-scale changes.
That's another good point.
I looked through the git history and it seems there are actually few tabbed
Dnia piątek, 18 stycznia 2013, Simon Marlow napisał:
I tried browsing to a couple of other commits and got the same error, so
it doesn't seem specific to that commit.
Some of the commits work:
http://hackage.haskell.org/trac/ghc/changeset/68833e5e8caa1c23f75ab8bea4377ede28ff9548
But I also
Dnia piątek, 18 stycznia 2013, Alexander Kjeldaas napisał:
Well if this is true, then I think you could solve this simply by looking
for this in a git commit hook or some other hook.
http://stackoverflow.com/questions/3985463/prevent-pushes-to-git-containing
I want to work on implementing primitive Booleans in GHC and thus resolve trac
ticket 6135 (
http://hackage.haskell.org/trac/ghc/ticket/6135 ). I haven't done any
development work on GHC yet
so this will be my first attempt to contribute something useful to the project.
However, I need
some
Unfortunately, I can't find any timescale for the release anywhere, but it's
currently frozen.
It's frozen for about 7 months now. Debian is released When It's Done and I
think the only
timescale you can find is the number of release-critical bugs:
http://bugs.debian.org/release-critical/
Dnia piątek, 1 marca 2013, Simon Peyton-Jones napisał:
I keep getting this when attempting to clone a fresh repo. Can anyone
help? Thanks
Perhaps a temporary downtime of the repo? Or web problems on your side. I just
cloned that repo
and things worked for me.
Janek
I'll chip in with my cries. Yesterday I spent 6 hours trying to track down a
build problem in GHC
HEAD. Turned out that it was caused by having two versions of binary package,
which were
installed to satisfy dependencies and silently broke my installation. I spent
another hour today
fixing
There's one big difference here: rpm/dpkg are only used to install
things by the system administrator. But in the case of Cabal, a user
could install 'mypackage' (in their user package database) and the next
day the sysadmin could install a different instance of 'mypackage' in
the global
I'm trying to set up a sandboxed installation of GHC HEAD with cabal-install
and some other
libraries. I need this to run some benchmarks on Repa library. Right now I'm
having problems with
bootstraping cabal-install. I managed to work around problems with some
pakcages like HTTP that
put
You can just make cabal use a different GHC for compilation, etc.
What I need to do is compile a single source file and examine the Core and ASM
dumps. It would be
much more convenient if I could do this by simply invoking GHC from the command
line instead of
creating a fake cabal package for
The way to do this is described on a wiki page in the developers corner:
http://hackage.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace
(scroll down
to Plan B on this page)
Thanks, that helped.
What I should have mentioned is that I am sandboxing my GHC installations, so
Where are all the fingerprints for the libraries? You only seem to have
the submodule libraries in there...
Whoops, I ran the fingerprint script in the build tree which doesn't have
symlinks to .git
directories. Is this version of the fingerprint correct?
Janek
occur.
Also, every developer would have to set this up on her own, whereas my proposal
is set up on the
central server and automatically affects everyone pushing to the repo.
Janek
Dnia poniedziałek, 25 marca 2013, Daniel Trstenjak napisał:
Hi Jan,
On Mon, Mar 25, 2013 at 03:36:38PM +0100, Jan
Daniel,
I'm also a bit ignorant as to why there are two different repos. Indeed putting
the testsuite into
the same repo as GHC seems to be the best option, but I'm assuming that since
the GHC team has
placed these projects into separate repos there must be a Good Reason to do so.
Or perhaps
I need some help with my work on ticket #6135. Consider this program:
{-# LANGUAGE BangPatterns, MagicHash #-}
module Main where
import GHC.Exts
main = print $ nan## ==## nan##
where !(D# nan##) = 0.0 / 0.0
This prints False, which is a correct implementation of IEEE754 standard.
However
]
| On Behalf Of Jan Stolarek
| Sent: 22 April 2013 13:48
| To: ghc-devs@haskell.org
| Subject: Handling of NaN
|
| I need some help with my work on ticket #6135. Consider this program:
|
| {-# LANGUAGE BangPatterns, MagicHash #-} module Main where
|
| import GHC.Exts
|
| main = print $ nan
they
are not NaNs (on the
other hand I doubt this rule would trigger often).
Janek
Simon
| -Original Message-
| From: Jan Stolarek [mailto:jan.stola...@p.lodz.pl]
| Sent: 22 April 2013 15:51
| To: Simon Peyton-Jones
| Cc: ghc-devs@haskell.org
| Subject: Re: Handling of NaN
|
| Same
OK. I thought it only applies to RULES pragma.
Janek
Dnia środa, 24 kwietnia 2013, Simon Peyton-Jones napisał:
Use -ddump-rule-firings to display rule firings
Simon
| -Original Message-
| From: Jan Stolarek [mailto:jan.stola...@p.lodz.pl]
| Sent: 24 April 2013 07:53
| To: Simon
Opening a ticket is a good idea - this problem has been iritating me as well
and in fact I almost
gave up on browsing GHC code on github.
As a side note it seems to me that writing literate Haskell is not really
popular and I would be
happy to see the source code of GHC converted to .hs one
Surely you're not asking everyone to change their coding convention to suit
your taste?
So, is literate Haskell everyone's coding convention? It seems to me that today
people are more
likely to document their code with Haddock and the code written in literate
Haskell is remnant of
a distant
I checked some older (with commits up to March 29, 2013) build trees and I
see that in libraries/integer-gmp/gmp there are files like gmp.h and
libgmp.a that are not present in my latest build tree.
Strange. I'm looking at the commit history at github and I see no gmp.h in the
repository in
, but not in the source trees.
I.e. when I check out the source these aren't present, but after I build
they are (at least in the past they were).
-Andi
On Fri, Apr 26, 2013 at 10:17 AM, Jan Stolarek jan.stola...@p.lodz.plwrote:
I checked some older (with commits up to March 29, 2013) build trees
7957ab015dc750fd66f2a34aa30f52544362e0f5 Mon Sep 17 00:00:00 2001
From: Jan Stolarek jan.stola...@p.lodz.pl
Date: Thu, 25 Apr 2013 16:07:35 +0200
Subject: [PATCH 1/3] Add --show-options to list all flags (Fixes #7843)
---
compiler/main/StaticFlags.hs | 11 ---
ghc/Main.hs | 20 +++-
2 files
Does this help:
git submodule update libraries/Cabal/
?
Janek
Dnia czwartek, 9 maja 2013, Simon Peyton-Jones napisał:
Help! I can't build ghc!
I get this
utils/ghc-pkg/Main.hs:1160:24:
Not in scope: `showSimpleInstalledPackageInfoField'
Perhaps you meant
...@haskell.org]
| On Behalf Of Jan Stolarek
| Sent: 10 May 2013 11:52
| To: ghc-devs@haskell.org
| Subject: Need help with debugging Impossible case alternative
|
| I'm working on modifying comparison primops so that they return Int#
| instead of Bool. I've been
| stuck with one bug for about two
2013, Jan Stolarek napisał:
Thanks Simon. I think I tracked down the source of the problem.
When I modified primops to return Int# instead of Bool I assumed that the
definition of what is True and False changes as well. So I changed
(prelude/PrelRules.lhs):
trueVal, falseVal :: Expr CoreBndr
Once again thanks for explanation! I found the problem, so now I only have a
handful of failing
tests, which hopefully will be easy to fix.
That's very dangerous! You *only* want to do this for the values returned
by your primops, not for anything else. Maybe that's the only way that
. Otherwise I've not
experienced the issues you mention. I'd point out though that GHC's
'no validate failures' is very frequently violated which did confuse
me a lot when getting started.
On 15 May 2013 05:10, Jan Stolarek jan.stola...@p.lodz.pl wrote:
This has never happened to me. I
The testsuite does check whether the package.cache timestamp changed
while running a test. If it did then you'll get a
Package cache timestamps do not match: [...]
framework failure. Do you know whether that happened?
If it checks cache local to the build tree, then I have no idea. I just
If you remove everything but the quotInteger test from
integerConstantFolding and compile with -ddump-rule-rewrites then you'll
see that the eqInteger rule fires before quotInteger. This is presumably
comparing against 0, as the definition of quot for Integer (in GHC.Real)
is
_ `quot` 0
When I run nofib the fft2 benchmark fails with an error (see below). This
happens both with HEAD
and 7.6.3. I'm setting the path to benchmarked GHC in mk/build.mk using option
WithNofibHc.
Anyone else is having the same problem?
Janek
././fft2 512 /dev/null
expected stdout not matched by
For me the biggest plus of switching to submodules would be keeping GHC and
testsuite in sync. If
there are any reasons not to change in-tree library repos to submodules, then I
would at least
want testsuite to be changed to a submodule.
I also use github for my daily work on GHC and being
I think that Iavor is facing the same problems that I reported on this list on
May 15th. I also
see ghcpkg01 failing (when run during the validation) and passing (when run
separately). This
sometimes happens with other tests as well. Iavor, are you getting 'cahce is
out of date' error
when
1) We could now delete ./sync-all if this happened.
In that case I would vote for replacing sync-all with a script that aids in
managing branches in
multiple subrepos. I implemented such a script for myself in a very ad hoc way.
Having something
more robust would be great.
2) One thing this
I think that testsuite should be included in the main GHC repo. I don't recall
any other project
that has its tests placed in a separate repository. The nhc argument doesn't
convince me - after
all, most test that are added nowadays are GHC specific.
Janek
When you ran it separately, did you say BINDIST=YES ? If you didn't then
it would have used the inplace package.conf.d, not the bindisttest one.
No, I didn't. When I run tests separately I only do 'make TEST=testName'.
Should I add BINDIST=YES
when rerunning this test or not?
I recently
You can be honest and just call them what they are: horribly written
novellas.
Actually, I was thinking that instead of posting to the list you might consider
publishing your
emails as papers on workshops or symposia ;)
for high-traffic repositories, some of the concerns are disconcerning.
Oh, and I've been made aware that git 1.7 and later can checkout a subdirectory
of a repo - this
partially invalidates my previous argument. I'm saying partially, because it is
a bit more
difficult than dealing with a library that has its own repo + it seems that
some potential
contributors
I'm repasting Stefan Holdermans' mail from Haskell-cafe, because it also
concerns this issue:
Hi all,
The last days, some spam was added to the GHC developer wiki
(http://hackage.haskell.org/trac/ghc) .
I have removed some of it, but I could not get rid of the bits that were
added
in a
program with a very hot loop is due to incidentally inhibiting some caching
behavior (instr? data?)? Or perhaps effecting alignment? FTR my CPU is a
Core i7-2620M, Sandy Bridge.
Thanks all.
On Wed, Jun 19, 2013 at 9:27 AM, Jan Stolarek jan.stola...@p.lodz.plwrote:
If it's not sorted out
The same tests consistently fail for me.
Even if you run them separately with 'make TEST=failingTest'?
I only get the errors when running the testsuite with BINDIST=YES, as
expected.
I'm running validation without BINDIST=YES at the moment, will run the second
validation later.
Where do you
I thought it was obvious that I only meant that it was reliable for me :)
Reliable for me is a bit of oxymoron in the context of validating correctness
of software :) I
guess that's why I titled this thread Unreliability of the build system.
I'm running ext4.
Is there any method by which you
I just ran validation (once without any parameters and once with --normal) and
got no failures,
except for some tests that always fail. Looks like the problem may be solved.
Janek
Dnia wtorek, 25 czerwca 2013, Geoffrey Mainland napisał:
On 06/24/2013 09:21 PM, Jan Stolarek wrote:
My only
Surprisingly (?), no T149 or process007.
Yes, you do have these tests failing:
Unexpected passes:
perf/should_run T149 (normal)
Unexpected failures:
../../libraries/process/tests process007 [bad stdout] (normal)
I learned not to worry about performance tests - they seem to be quite
This makes me sad. You should shout when performance tests fail.
Even if they sometimes fail and sometimes not?
Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hi Simon,
as part of my internship at MSR I'm working on optimizing the new code
generator. My starting point is Krzysztof Woś's project Low-level code
optimizations in the Glasgow Haskell Compiler [1]. Right now I'm trying to
figure out which of the described optimisations are currently
Thank you both for explanations. I will try to clean up the code of Cmm
pipeline a little bit.
Janek
- Oryginalna wiadomość -
Od: Simon Marlow marlo...@gmail.com
Do: Jan Stolarek jan.stola...@p.lodz.pl
DW: ghc-devs@haskell.org
Wysłane: czwartek, 11 lipiec 2013 17:52:49
Temat: Re: Some
- Oryginalna wiadomość -
Od: Simon Marlow marlo...@gmail.com
Do: Jan Stolarek jan.stola...@p.lodz.pl
DW: ghc-devs@haskell.org
Wysłane: czwartek, 11 lipiec 2013 17:52:49
Temat: Re: Some more questions about Cmm pipeline
1. Was a quick hack that I did sometime in the past, it probably didn't
Thank you for detailed response.
1. PLEASE make sure that you're carefully measuring compilation time
when making changes to the code generator.
Noted.
Furthermore, think carefully about how much effort you want to
put into Cmm optimisation against what we can already get for free with
At the moment I keep getting timeouts when I try to access the wiki. Not sure
if this is a temporary problem or something more persistent.
Janek
- Oryginalna wiadomość -
Od: Edward Z. Yang ezy...@mit.edu
Do: Ian Lynagh i...@well-typed.com
DW: ghc-devs ghc-devs@haskell.org
Wysłane:
I've done a performance build today on a 64 bit linux and the shared libraries
weren't build. I had to comment out these 3 lines in perf section of build.mk
to get the shared libraries built:
ifeq $(PlatformSupportsSharedLibs) YES
GhcLibWays += dyn
endif
Is that expected?
Janek
It seems that currently there are no built-in constant folding rules for
Integer div and mod. I plan on adding those rules, but before I do that I
wanted to ask whether there is a good reason that these rules don't exist?
Janek
___
ghc-devs mailing
I have two questions about using Hoopl:
1) I'm debugging some Hoopl transformations that often fall into an infinite
loop. Probably the easiest way to find the cause would be to allow only a
limited number of iterations and then examining the rewritten output. I think
that optimization fuel
T5321FD and T5321Fun are failing with HEAD - performance stat is too good.
Looks like the allocation has decreased. Did anyone notice when this
improvement happened?
Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
= CmmStore lhs (CmmReg newReg)
return . Just . GUnit . BCons newRegAssign . BMiddle $ newMemAssign
Is this a correct way of generating new Uniques? If this function is evaluated
twice will it generate two different uniques?
Janek
- Oryginalna wiadomość -
Od: Jan Stolarek jan.stola
% just by
accident. Perhaps this would be another such case?
Janek
- Oryginalna wiadomość -
Od: Simon Peyton-Jones simo...@microsoft.com
Do: Jan Stolarek jan.stola...@p.lodz.pl, ghc-devs ghc-devs@haskell.org
Wysłane: piątek, 26 lipiec 2013 16:57:23
Temat: RE: T5321FD and T5321Fun
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 be
I spent whole day looking for a bug that lurks somewhere in my code, but I know
I could find it in 2-3 hours if I only could write unit tests for my code. So
the question is: how can I write HUnit and QuickCheck (and maybe SmallCheck)
tests for GHC and possibly make them a part of testsuite?
reach end of a
loop we will propagate (Const ...) to the entry block of a loop and only then
we will be joining two (Const ...) facts - that's when second equation of
joinCpFacts should come in to play.
Janek
- Oryginalna wiadomość -
Od: Jan Stolarek jan.stola...@p.lodz.pl
Do: Edward Z
Better yet, the sync-all script should detect whether it is on master and
error out (with a decent error message) if not.
Why? I think it is behaving properly - it fetches master branch from the server
and merges it into
local master branch, just as expected. I imagine that switching to master
I just want to add that I have exactly the same problem.
Janek
- Oryginalna wiadomość -
Od: Richard Eisenberg e...@cis.upenn.edu
Do: ghc-devs@haskell.org
Wysłane: poniedziałek, 5 sierpień 2013 10:53:57
Temat: libffi-tarballs
After the libffi-tarballs submodule was added, I did a
I have a question about this piece of Cmm code:
cJI:
R1 = _sGG::P32;
call (stg_gc_enter_1)(R1) args: 4, res: 0, upd: 4;
cJK:
...
Does the call to stg_gc_enter_1 return to cJK: a) never; b) sometimes; c)
always ? I'm looking at the implementation in rts/HeapStackCheck.cmm
When I'm pushing to testsuite repo I get lots of warnings:
[t-jastol@cam-05-unx : ~/ghc-working/testsuite] git push origin master
Counting objects: 13, done.
Delta compression using up to 32 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 783 bytes, done.
Total 7
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 = complicated_expr
I32[(old + 4)] = newReg1
The next question is well how do I do this then?. I'm not quite sure,
maybe you need to use a deterministic name supply monad.
So why are Hoopl's rewrite functions specialized to UniqSM monad? My
understanding so far was that this is precisely because we need access to Uniq
supply to
Lesson learned (for me at least): add regression tests to the testsuite when
reporting compiler failures.
Janek
- Oryginalna wiadomość -
Od: Kazu Yamamoto (山本和彦) k...@iij.ad.jp
Do: ghc-devs@haskell.org
Wysłane: środa, 14 sierpień 2013 7:39:10
Temat: Re: Segfault on x86 with -O2
Hi,
It
Btw, if this is desired, we could make a
commit add a ticket comment as soon as the respective ticket-number
occurs (i.e. w/o any preceding verb).
I consider this useful. I want to write commit messages in the tesuite like
Add regression test for #1234 instead of Add regression test. See
One possibility is to do this transformation once and for all, *before* the
constant-prop pass,
since it is not dependent on the facts generated by the pass.
Yes, that was Geoffrey's suggestion as well. I'll do that once I fix some
remaining issues in copy propagation.
Janek
When I do full testsuite run (either with 'make fulltest' or './validate
--slow') there is a bunch of DPH tests which take Very Long Time to run
(approx. half of the time needed to run testsuite, if not more). These tests
are consistently failing. What would DPH team and others say to disabling
for me personally Bool would be even better
To get a Bool you can use wrappers defined in the same module, e.g.:
geInt64# :: Int64# - Int64# - Bool
geInt64# a b = tagToEnum# (int64ToInt# (geInt64## a b))
Looking at the implementation of this wrapper I think Luite has a point - to
get a Bool
OK, will fix that ASAP.
Janek
Dnia czwartek, 15 sierpnia 2013, Simon Peyton-Jones napisał:
Yes I agree: native Int#!
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Carter
Schonwald Sent: 15 August 2013 17:43
To: Jan Stolarek
Cc: ghc-devs
Subject: Re: Change
Right now we have a git hook that prevents pushing a file containing tabs,
unless that file had them already (in other words: no new files with tabs in
our repos). I propose to add similar hook for trailing whitespaces. Herbert
says he can implement that. What do others think? Would you find
Details here: do please modify directly:
http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
Feature I was working on has been merged into HEAD. Should I remove it from the
list?
Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi Gabor,
I get these errors when building a cabal package:
(...)
I guess this is related to those changes.
Yes, that's because of my patches.
If yes, what to do next? Contact the 'primitive' maintainer?
It's just like with any other backwards-incompatible changes in GHC - package
Hmm, almost, but I get now:
(...)
How to repackage Int# to Bool?
Oh dear... that's that 5% :) You just want sameMutableArray instead of
sameMutableArray#. There will be problems with sameMVar and so on (if primitive
uses them - I don't remember), but that's fixed in a similar way. A quick
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 want in Hoopl.
Janek
1. Why do you say this naming feels more consistent? Consistent with what?
Convention is that functions ending with # operate on unboxed values and return
unboxed values (usually), so to me it seemed consistent that sameTVar# returns
an unboxed value, while sameTVar does not. I raised that
- Oryginalna wiadomość -
Od: Jan Stolarek jan.stola...@p.lodz.pl
Do: Simon Peyton-Jones simo...@microsoft.com
DW: ghc-devs@haskell.org, Gabor Greif ggr...@gmail.com
Wysłane: czwartek, 22 sierpień 2013 14:43:29
Temat: Re: Changes to primops break libraries (was Re: 7.8 Feature window)
1. Why do you
of GHC.PrimWrappers module than these page will need to be updated accordingly.
Janek
- Oryginalna wiadomość -
Od: Simon Peyton-Jones simo...@microsoft.com
Do: Jan Stolarek jan.stola...@p.lodz.pl, Gabor Greif ggr...@gmail.com
DW: ghc-devs@haskell.org
Wysłane: czwartek, 22 sierpień 2013 13:40:09
You're right Simon - I didn't thought about ltFloat and that my idea of
consistency breaks there.
Janek
- Oryginalna wiadomość -
Od: Simon Peyton-Jones simo...@microsoft.com
Do: Jan Stolarek jan.stola...@p.lodz.pl
DW: ghc-devs@haskell.org, Gabor Greif ggr...@gmail.com
Wysłane: czwartek
Sure. I considered that idea at some point but it seemed a bit to drastic.
Janek
- Oryginalna wiadomość -
Od: Simon Peyton-Jones simo...@microsoft.com
Do: Geoffrey Mainland mainl...@apeiron.net, Jan Stolarek
jan.stola...@p.lodz.pl
DW: ghc-devs@haskell.org
Wysłane: czwartek, 22 sierpień
...@microsoft.com
Do: Simon Marlow marlo...@gmail.com, Jan Stolarek jan.stola...@p.lodz.pl
DW: ghc-devs ghc-devs@haskell.org, n...@cs.tufts.edu, d...@cs.tufts.edu,
Edward Z. Yang ezy...@mit.edu
Wysłane: czwartek, 22 sierpień 2013 17:44:11
Temat: RE: Changes in Hoopl
I have elaborated (more clearly I hope)
S
I am working on improving new comparison primops and implementing Geoffrey's
proposal [1]. I
renamed GHC.Prim to GHC.Prim.BuiltIn and GHC.PrimWrappers (in ghc-prim library)
to GHC.Prim. I
can build the compiler and testsuite passes succesfully, but ./validate fails
with 'haddock
panic' when
Previously the tagToEnum# was optimised away in the code generator in
the common cases. Perhaps the Simplifier will do that for the wrappers
now, I don't know.
This special case is still in the code generator and it will be there until we
move handling of
tagToEnum# to Core. So using
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
GHC.Prim.BuiltIn [1]. This way
change will be
I guess that's a valid argument. I'll discuss this with Simon tomorrow.
Janek
Dnia poniedziałek, 26 sierpnia 2013, Simon Marlow napisał:
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
The problem with these kind of commit-time checks is that you only find
out the problem *after* you've validated your nicely polished commits.
This is easily solved by adding this line to .emacs file:
(add-hook 'before-save-hook 'delete-trailing-whitespace)
No more trailing whitespaces.
The problem with this approach is that if a file already contains
trailing whitespace, you'll introduce spurious changes in your commit.
I wouldn't call it a problem, but a feature - provided that you put whitespace
changes in a separate commit. In this way we would gradually get rid of all
Good, we have a culprit then. Kazu, would you be willing to do a couple of
things to provide me
with more information? I'd need the Cmm dump that causes the panic. Also,
tomorrow I'll add more
information to this panic so that we get back name of offending code block -
this should make
Thanks Kazu! This should get me going. Can you temporarily work with my commit
reverted? I should have some time to look into this at the end of this week.
It's interesting that this time you got failure for a different file than in
your original email to the list. Seems like the error was
I am refactoring new Bool primops (#6135). There was a discussion on
core-libraries-commitee list and the decision was made that we should keep
names of primops we used so far and change their type signature (right now HEAD
has different names for new primops and reuses old names for
: Geoffrey Mainland mainl...@apeiron.net
Do: Jan Stolarek jan.stola...@p.lodz.pl
DW: ghc-devs ghc-devs@haskell.org
Wysłane: poniedziałek, 9 wrzesień 2013 15:40:09
Temat: Re: Alex and new Bool primops
Perhaps the core libraries committee should reconsider their decision?
:) Backwards compatibility
- this moment is as good as any other.
Janek
- Oryginalna wiadomość -
Od: Simon Peyton-Jones simo...@microsoft.com
Do: Michael Snoyman mich...@snoyman.com
DW: core-libraries-commit...@haskell.org, ghc-devs ghc-devs@haskell.org,
Geoffrey Mainland mainl...@apeiron.net, Jan Stolarek
I have problems with validating my changes in template-haskell, file
Language/Haskell/Th/Syntax.hs. I added isTrue# function in the import:
import GHC.Base ( Int(..), Int#, (#), (==#), isTrue# )
And later on I'm using isTrue#. However, when stage1 compiler tries to compile
Syntax.hs,
-Jones simo...@microsoft.com
DW: core-libraries-commit...@haskell.org, ghc-devs ghc-devs@haskell.org,
Geoffrey Mainland mainl...@apeiron.net, Jan Stolarek
jan.stola...@p.lodz.pl, Simon Marlow marlo...@gmail.com
Wysłane: środa, 11 wrzesień 2013 5:04:24
Temat: Re: [core libraries] RE: Alex and new Bool
I second Edward's question. I need to do a profiling build of GHC, but I'm
getting segfaults.
Janek
- Oryginalna wiadomość -
Od: Edward Z. Yang ezy...@mit.edu
Do: ghc-devs ghc-devs@haskell.org
Wysłane: niedziela, 8 wrzesień 2013 6:39:20
Temat: Profiling segfaulting in HEAD again
Hey
Kazu,
take a look here, there's a workaround:
http://ghc.haskell.org/trac/ghc/ticket/8276
Thanks for tracking possible cause of this panic.
Janek
- Oryginalna wiadomość -
Od: Kazu Yamamoto k...@iij.ad.jp
Do: ghc-devs@haskell.org
Wysłane: piątek, 13 wrzesień 2013 4:06:30
Temat: build
I recall that David solved his problem by pulling a fresh tree from main repo.
So it was fault of his tree, not your patch.
Janek
- Oryginalna wiadomość -
Od: Iavor Diatchki iavor.diatc...@gmail.com
Do: David Luposchainsky dluposchain...@googlemail.com, ghc-devs@haskell.org
Wysłane:
1 - 100 of 297 matches
Mail list logo
