Hi all,
I've merged the new parallel I/O manager that Andreas Voellmy and Kazu
Yamamoto have been working on. The new parallel I/O manager scales much better
than the current one*: the number of requests per second scales almost
linearly up to 32 cores I believe. Perhaps Andreas could post
Hello,
These days I can validate GHC head on Mac. But to my surprise, I
cannot build GHC head on Mac. I verified this with both 32bit and
64bit bootstrapping GHC on Mac. Any ideas?
inplace/bin/ghc-stage1 -static -prof -H32m -O-package-name
hoopl-3.10.0.0 -hide-all-packages -i
Hi,
First of all, I would like to ask whether or not someone can build
(not validate) GHC head on Mountain Lion. The reason why I ask is
that I found this issue:
http://stackoverflow.com/questions/13539066/can-write-to-a-non-blocking-fd-return-eagain-when-select-reports-it-as-writabl
Hi,
I started to look into fixing this issue, but HEAD no longer
compiles for me. Here is the build error I get (on os x 10.8.2):
The same problem happens on my Mac since yesterday.
Watching this compiling the file by dtruss changes its
behavior. That is, compiling the file finishes. But
Hi,
GHC head cannot be build on FreeBSD 9.1:
libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No
such file or directory
compiler/ghc.mk:426: compiler/stage1/build/.depend-v.haskell: No such file or
directory
cp -p utils/hsc2hs/dist/build/tmp/hsc2hs
Hello,
cp -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/bin/hsc2hs
utils/hsc2hs/ghc.mk:15: *** Do not know how to prependLibraryPath on
freebsd. Stop.
gmake: *** [all] Error 2
It's trying to do the equivalent of setting LD_LIBRARY_PATH or
DYLD_LIBRARY_PATH (see
Hllo,
and the build error:
inplace/bin/ghc-stage1 -static -H32m -O-package-name
ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/.
[...]
libraries/ghc-prim/dist-install/build/GHC/IntWord64.o -dyno
libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o
In my case:
libffi.so.6 = not found (0)
Ah, I'm optimistic that
commit 51bf3653775ba734f7ca3de99234aba722a0c72c
Author: Ian Lynagh i...@well-typed.com
Date: Wed Mar 20 19:25:27 2013 +
Fix build with non-Linux ELF OSes
will fix this.
This fix does not
I tried to install the vanilla binary tarball that the builder client
created this morning [1] (i386), but I got the following errors at
install:
I think this kind of errors should not be occurred anyway.
Note that I set sudo -w vfs.timestamp_precision=1 on FreeBSD
according to:
Hi,
I have created a ticket about Dynamic linking and libffi:
http://hackage.haskell.org/trac/ghc/ticket/7806
--Kazu
OK, I've just pushed another attempt; can you let me know whether HEAD
now works for you, please?
Thanks.
That's expected. All the Haskell .so's should also be
Richard,
Here's the end of my output:
Installing library in
/Users/rae/local/stow/ghc-head/lib/ghc-7.7.20130403/haskell2010-1.1.1.0
/Users/rae/local/stow/ghc-head/lib/ghc-7.7.20130403/bin/ghc-pkg --force
--global-package-db
Gabor,
I thought this issue is closed, until I tried to re-bootstrap on OS X
with a freshly built GHC from HEAD as bootstrap compiler. I get the
same trap, and the ffi dylib issue. 7.7-20130223 works, yesterday's
version doesn't. The problem appears already while configuring. Could
you try
After make install, the installed GHC refers libffi in the build
directory.
% otool -L ghc | grep libffi
/Users/kazu/work/ghc/libffi/build/inst/lib/libffi.6.dylib (compatibility
version 7.0.0, current version 7.0.0)
So, after I did make maintainer-clean, the installed GHC could not
Hello,
When building GHC head, primitive and vector are also compiled. But
make install does not install them. Are there any way to install
primitive and vector in addition to other libraries?
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Hello,
The tarball created by make binary-dist includes them but
./configure; make install does not install them, either.
Now I believe this is a bug.
--Kazu
Hello,
When building GHC head, primitive and vector are also compiled. But
make install does not install them. Are there any way to
Hi Geoff,
Try adding the following to mk/build.mk:
InstallExtraPackages = YES
Thank you for letting me know this. It worked!
I hope this is explained in mk/build.mk.sample.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
I'm trying to validate GHC head with GCC 4.7 on FreeBSD. I run
validate without any modifications:
% config_args=--prefix=/ghc-head
--with-iconv-includes=/usr/local/include
--with-iconv-libraries=/usr/local/lib
Hi,
threadDelay of GHC head causes seqfault or bus error on 32bit machine
including Mac and Linux. This bug does not exist as least in GHC
7.4.2.
This bug is due to atMost of GHC.Event.PSQ. After modifying
libraries/base/base.cabal to export GHC.Event and building GHC head,
the following code
Hi,
I should say that I tested this on Linux.
--Kazu
Hi,
GHC head of today cannot link installed libraries. When I tried to
install lifted-base, the following error occurred:
[6 of 6] Compiling Control.Concurrent.Lifted ( Control/Concurrent/Lifted.hs,
Hi Nicolas,
TEST=T149 T5313 jules_xref launchbury layout008 jl_defaults T7360 T1969
T5631 T3064 T4801 T3294 jules_xref2 ImpSafeOnly08 safePkg01 ImpSafeOnly02
ImpSafeOnly03 ImpSafeOnly01 ImpSafeOnly06 ImpSafeOnly07 ImpSafeOnly04
ImpSafeOnly05 ImpSafeOnly09 ImpSafeOnly10 T4474a T4474c T4474b
Hi Ian,
This caused an error:
Configuring terminfo-0.3.2.5...
configure: WARNING: unrecognized options: --with-compiler,
--with-iconv-includes, --with-iconv-libraries, --with-gmp-includes,
--with-gmp-libraries, --with-gcc
checking for gcc... cc
checking whether the
Hi,
After a long fight, I found that this is a bug of the -O2 option of
GHC head on 32bit machine. Now, it is easy to reproduce this
segfault. Please read and try this:
https://github.com/kazu-yamamoto/buggy-psq
Note that this segfault does not occur when -O' is specified.
--Kazu
Hi,
There are a lot of things to recommend moving to github. I do hate
(non-empty) merge commits, though, so I'm not a fan of github's pull
request mechanism.
Please read A successful Git branching model to know why fast-forward
is not used recently.
Git flow:
Hi Geoffrey,
I am of the opinion that major feature branches should be rebased
*and* that they should then be merged with --no-ff.
I totally agree with you. :-)
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
I think you've to differentiate the case of merging a feature branch
into the master branch and the case of merging a local with a remote
branch, like just calling git pull/push on the master branch.
I just wanted to say that first forward merge loses information about
which sequence of
Hi,
We misunderstood that the new IO manager was not working
properly. This is our fault. We confirmed that it is working
well. Sorry for bothering you, guys.
Anyway, I believe we need a way to check out proper submodules as many
others said.
--Kazu
Hi,
Andreas and I found that the new IO
Hi,
I seems to me that shared libraries for profiling are not installed.
For example, let's see the base library:
% cd lib/ghc-7.7.20130616/base-4.7.0.0
% ls -1 libHSbase*
libHSbase-4.7.0.0.a
libHSbase-4.7.0.0-ghc7.7.20130616.so*
libHSbase-4.7.0.0_p.a
A
Hi,
When I try to install libfted-base, cabal uses dynamic-linking while
it uses static-linking for other libraries. So, I got the following
error:
% cabal install lifted-base
/usr/bin/ld: cannot find -lHSmonad-control-0.3.2.1-ghc7.7.20130616
/usr/bin/ld: cannot find
Hi,
The following command can install acme-http with profiling if GHC
7.6.3 is used:
% cabal install -p --ghc-options=-prof -fprof-auto
--enable-executable-profiling -j10 acme-http
But if GHC head is used, the following error occurs:
% cabal install -p --ghc-options=-prof
Yes, this is a bug; see #7978. I am working with Simon to get it fixed.
Thanks. I joined the ticket.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hi,
I got an build error on Mac today:
make -r --no-print-directory -f ghc.mk phase=final all
inplace/bin/ghc-stage1 -o utils/dll-split/dist-install/build/tmp/dll-split
-hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O
-hide-all-packages -i -iutils/dll-split/.
Hi Austin,
Once my Mac is back online I'll push my changes again, hopefully
without err. :)
Fixed. Thank you!
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hi,
A recent change[1] to sync-all introduces the ~~ operator of
Perl. It seems to me that this operator is not supported by old Perl.
% perl --version
This is perl, v5.8.8 built for i386-linux-thread-multi
% ./sync-all -r git://github.com/ghc --testsuite get
Hi,
I'm using GHC head (32bit) on Mac. Recently, building GHC head
stops:
% make maintainer-clean; perl boot; ./configure --prefix=/ghc-head; make -j3
ranlib: file: .libs/libgmp.a(mp_clz_tab.o) has no symbols
ranlib: file: .libs/libgmp.a(obprintf.o) has no symbols
ranlib: file:
Erik,
Sorry for using old Perl but I appreciate if this operator will be
replaced with others.
Thanks for the heads up Kazu.
Should be fixed in 0daee297e3c44c00f54d2be15f13eabdddc6b62f.
Thank you for your quick fix. It works!
--Kazu
___
Hi Nicolas,
My guess is here: libraries/integer-gmp/configure generates gmp.h.
Building mkGmpDerivedConstants starts in parallel. Since configure
takes time, mkGmpDerivedConstants is build before gmp.h is
created.
How can we ensure that these two jobs are carried out sequentially?
--Kazu
I
Hi,
Some changes in the last 8 days fixed segfault on 32bit x86 with -O2:
http://ghc.haskell.org/trac/ghc/ticket/7953
I read recent log messages but I cannot guess which commits fixed this
bug. Does anyone guess?
P.S.
Thanks to this, now I started running Mighty with multicore IO
Hi,
It seems to me that #8116 (only for GHC head) was also fixed. :-)
--Kazu
And just for the record, people reported this morning they couldn't
reproduce #8103 anymore, and I'd bet this probably fixes that one,
too.
On Tue, Aug 13, 2013 at 10:17 PM, Austin Seipp ase...@pobox.com wrote:
Simon,
We have a ticket for this:
http://ghc.haskell.org/trac/ghc/ticket/8102
We guessed the source of this bug as described in this ticket but I
don't know how to write GNU Makefile.
--Kazu
Austin
This looks like a make-system bug, based on a cursory read. Worth a ticket?
Do
Austin,
Kazu - perhaps are you still seeing this consistently on your Mac?
Yes, I still have this problem.
$(libraries/integer-gmp/mkGmpDerivedConstants_dist_depfile_c_asm):
libraries/integer-gmp/gmp/gmp.h
Thank you for this clue.
It seems to me that the following patch fixes this
Hi,
The following code should print string anyway.
https://gist.github.com/kazu-yamamoto/6265119/raw/1da32b8740222076e612373a715aa79732ce6756/gistfile1.hs
But if I execute it with runghc on 32 bit Mac and 32 bit Linux, it
terminates silently. If complied, it works. If I execute it with
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 so, the server cannot accept any HTTP requests. No
error messages from the server.
The server is alive. To terminate the server (running in a screen
Hi Andi,
What sort of workload was the mighty server under during those 1 or 2 days
while you waited for it to become unresponsive. I.e. was this a production
web server? Or were you generating requests at some frequency or leaving it
mostly idle?
I ran Mighty on http://mew.org. This is my
Hello,
GHCi of GHC 7.7 use Unicode quote marks instead of ASCII quote marks.
Why do you guys decide this behavior change? I'm just curious.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hi,
One guy suggested this ticket.
http://ghc.haskell.org/trac/ghc/ticket/2507
--Kazu
From: Gabor Greif ggr...@gmail.com
Subject: Re: Unicode quotes
On 9/4/13, Kazu Yamamoto k...@iij.ad.jp wrote:
Hello,
GHCi of GHC 7.7 use Unicode quote marks instead of ASCII quote marks.
Why do
Hi,
If you need two Ctrl-Cs to kill the program, it probably means that it
deadlocked somewhere, maybe in the RTS. Kazu: if you can attach to
the deadlocked process with gdb and get stack traces of all the
threads, that might help.
To debug with GDB, I complied Mighty with -debug. This
Hi,
I believe this is related to
http://ghc.haskell.org/trac/ghc/ticket/8205 - can you try:
$ git revert d61c3ac186c94021c851f7a2a6d20631e35fc1ba
and see if your build finishes? Perhaps you can help Jan diagnose it if so...
Yes. After this command, I can build GHC head on Mac.
--Kazu
Hi,
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
Hi Austin,
I would like to ask about profiling and dynamic linking.
If I understand correctly, GHC 7.8 with cabal-install 1.18.x.x uses
dynamic linking by default (except on FreeBSD). But GHC 7.8 provides a
profile library only for static linking. An example is the base
library:
Hi,
Austin, thank you for explanation.
Fortunately or unfortunately, I can build GHC head today without any
reverting. I will reset the GHC tree to yesterday and try again.
--Kazu
Hello Kazu, thank you for the help!
Here is the easiest way to get the output. First, run 'make' once by
Austin,
Dynamic should be available with anything, including profiling. This
is probably more an artifact of your mk/build.mk setup.
My mk/build.mk contains just one line:
InstallExtraPackages = YES
If you have a build tree, you can do:
$ make show VALUE=GhcLibWays
which should print
Hi,
Fortunately or unfortunately, I can build GHC head today without any
reverting. I will reset the GHC tree to yesterday and try again.
Never mind. This is my misunderstanding.
I cannot build GHC head today. I sent necessary information to Jan and
Austin personally.
--Kazu
Hi,
I built GHC head today (with d61c3ac186c94021c851f7a2a6d20631e35fc1ba
reverted). While I'm supporting GHC head for doctest on Mac, I found
the following problems relating to dynamic linking:
(1) Every .dylib installed with GHC head refers to itself in its
build directory. E.g.
%
Hi,
Thanks Kazu! This should get me going. Can you temporarily work with
my commit reverted?
Yes. I got this log without reverting. And now I'm using GHC head with
your commit reverted.
It's interesting that this time you got failure for a different file
than in your original email to the
Hi,
While I support GHC head for doctest, I encountered the following
bug.
doctest uses a GHCi subprocess to evaluate an expression represented
in String. Stderr from GHCi is merged into stdout by hDuplicateTo in
the GHCi side. Even evaluating an error expression, for instance 1
`div` 0, the
Hi,
Kazu (or someone else), can you please file a ticket on the Cabal bug
tracker [1] if you think that this a Cabal bug?
I'm not completely sure yet.
GHCi 7.8 uses dynamic linking. This is true.
So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they
supposed to use dynamic
Hi,
I found a workaround for this problem.
https://github.com/sol/doctest-haskell/issues/57
--Kazu
Hi,
While I support GHC head for doctest, I encountered the following
bug.
doctest uses a GHCi subprocess to evaluate an expression represented
in String. Stderr from GHCi is
Hi,
I cannot build GHC head today on Linux. It seems to me that
this bug is relating to the followings:
https://github.com/sol/doctest-haskell/issues/59
https://github.com/sol/doctest-haskell/pull/60
Why did the initial value of v_opt_C_ready in GHCI change?
--Kazu
Haddock
Hi Páli,
Please read:
http://ghc.haskell.org/trac/ghc/ticket/8276
--Kazu
Hi there,
I have been recently experiencing some problems with haddock in head
on FreeBSD, spotted by both of my builder clients [1,2], but quite
reproducible on a recent FreeBSD system too:
[snip]
Andi,
Is there a workaround for http://ghc.haskell.org/trac/ghc/ticket/8276. I
haven't been able to build HEAD for a while due to this issue.
Put the following one line to your mk/build.mk.
HADDOCK_DOCS = NO
The entire contents of my build.mk is:
InstallExtraPackages = YES
Hi all,
To check ticket #8139, I'm wondering whether or not I should install
XCode 5 to my MacBook Air. I heard that GCC will be removed if XCode 5
is installed. I also heard that if we modify lib/settings of GHC
7.6.3, GHC 7.6.3 can work with clang.
So, my question: how can I build GHC head
Hi,
What change did we think we need for a GHC 7.6.4 to support Xcode 5? Was it
just this change to fiddle with the command line options?
I don't know what is the best. But here is what I know now:
clang-xcode5-wrapper.hs (*1) works as a wrapper in many cases so
far. We need to change the
Hi,
As I wrote in the following blog article, I could build GHC head on
Mavericks 20 days ago.
http://d.hatena.ne.jp/kazu-yamamoto/20131028/1382921924
But I cannot build it recently:
/usr/bin/ghc -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db
Hi Carter,
Nick Partridge hit this recently and he's got PR's pending for Happy and
Alex https://github.com/simonmar/alex/pull/37 and
https://github.com/simonmar/happy/pull/12
I'm not using GCC. (In my previous message, I made a typo. GCC
should be read as clang). So, I think that this is a
Hi,
Adding the -v option, GHC displays:
*** Checking old interface for main:Lexer:
*** Parser:
*** Renamer/typechecker:
built-in:2:2: Not in scope: `#'
-keep-tmp-files keeps generated .hscpp file. The beginning of the
generated .hscpp is:
# 1
Hi,
I can finally build GHC head on Mavericks. I gave up on clang and
installed GHC 4.8 with MacPorts.
Then, I compiled alex and happy with GHC 7.6.3/GHC 4.8. With this, I
can build GHC head.
This step is a MUST. If alex and happy are complied GHC
7.6.3/clang-wrapper, I cannot build GHC head
Hi,
so what are you proposing?
I'm not proposing anything. I just want to share information so that
we can find a good solution.
Are you agreeing that those patches work with clang wrapper, but
also remarking that its unfortunate that such a hack is needed?
As I said, nkpart's patches are
Was there an issue if you used a wrapped clang and those patches or not?
I'm really confused.
Even with GHC/clang-wrapper and alex/happy with Nick's patches, I
cannot build GHC head. (I'm not using GCC 42 at all in this case.)
AlexTemplate (pre-processed by clang) has linemarkers like this:
Hi,
I'm try to make GHC head stably buildable with clang/wrapper on
Mavericks because we cannot ask all Mavericks users to install
apple-gcc or GCC.
The last big item for me is integer-gmp. GHC head cannot be built with
clang/wrapper if integer-gmp is used. (integer-simple is OK.)
This is
are you sure gmp/ghc.mk is removed? After all, it's a file checked into Git:
Oh. Probably I was confused.
So, should we introduce a hack for Mavericks to gmp/ghc.mk?
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
Oh. Probably I was confused.
So, should we introduce a hack for Mavericks to gmp/ghc.mk?
OK. I created a patch:
https://ghc.haskell.org/trac/ghc/ticket/8497#comment:8
With this patch, I can build GHC head/integer-gmp with GHC
7.6.3/clang-wrapper on Mavericks/XCode 5. (Note that
Hi,
Kazu, can you put create pull requests for happy and alex with your
required changes?
I have one concern.
The version of alex on Hackage is 3.1.2. But that of github is
3.1.1:
https://github.com/simonmar/alex/blob/master/alex.cabal
# This inconsistency exists in happy, too.
Did
I think he has forgotten, yes. But yeah do send the pull requests anyway,
my last set got merged in.
Done:
https://github.com/simonmar/happy/pull/13
https://github.com/simonmar/alex/pull/38
--Kazu
___
ghc-devs mailing list
Hi,
Recent GHC head on 32bit Linux cannot build conduit-1.0.9.2. (See the
attached log.) A while ago, GHC head on 32bit Linux could build it.
The same GHC head on 64bit Linux can build it.
Michael Snoyman suggested me to add ImpredicativeTypes. When I added
it to the Internal.hs, GHC head on
Hi,
I cannot build GHC head on Linux and Mac (Mavericks) today:
compiler/typecheck/TcEvidence.lhs:152:16:
Not in scope: data constructor `ASSERT2'
compiler/typecheck/TcEvidence.lhs:174:5:
Not in scope: data constructor `ASSERT2'
compiler/typecheck/TcEvidence.lhs:489:15:
Not in
Hi,
I cannot build GHC head on Linux and Mac (Mavericks) today:
compiler/typecheck/TcEvidence.lhs:152:16:
Not in scope: data constructor `ASSERT2'
The attached patches are necessary to build GHC head on Mavericks.
--Kazu
diff --git a/compiler/coreSyn/CoreUtils.lhs
Hi,
5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced
__builtin___clear_cache. I think this is GCC specific.
So, Storage.c cannot be compiled with clang:
rts/sm/Storage.c:1294:3:
error: use of unknown builtin '__builtin___clear_cache'
[-Wimplicit-function-declaration]
btw, curiously, Clang seems happy to compile ASSERT (...) occurences
in C files such as rts/STM.c which have several of those...
Yes. Clang supports it according to my test.
I don't know why this happens.
--Kazu
___
ghc-devs mailing list
Hi,
I was discussed this with Austin in private messages. He understand
what's the source of this problem and will fix it.
--Kazu
On 2013-11-29 at 03:37:43 +0100, Kazu Yamamoto (山本和彦) wrote:
5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced
__builtin___clear_cache. I think this is GCC
Hi Simon,
I think he has forgotten, yes. But yeah do send the pull requests
anyway,
my last set got merged in.
Done:
https://github.com/simonmar/happy/pull/13
https://github.com/simonmar/alex/pull/38
I've merged these and made new releases of Happy (1.19.2) and Alex
(3.1.3).
Hi,
many many folks are wondering about when 7.8 is going to hit RC officially.
What are the bugs / blockers / etc that are left to deal with?
We should at least aim to communicate whats going on instead of leaving
folks wondering.
Would somebody answer this question?
I'm also wondering.
Hi,
When I tried to build the SHA library with GHC head on on 32bit Linux,
GHC head got panic. GHC 7.4.2 can build SHA on the same machine.
Configuring SHA-1.6.1...
Building SHA-1.6.1...
Failed to install SHA-1.6.1
Last 10 lines of the build log (
Hi,
For Mac, we should verify darchon's Cabal patch for dynamic linking in
#8266. darchon's patch does not works well in my Mavericks.
https://ghc.haskell.org/trac/ghc/ticket/8266
If you guys are Mac users, please test darchon's patch.
Also, a problem exists in FreeBSD:
Austin,
Blargh, I'll fix this shortly. Thanks Pali.
Please do. I also hit upon this bug. I could build GHC head yesterday
but not today.
P.S.
Even if this is fixed, validate does not work on my Mac recently due
to a haddock problem of the xhtml library. Does anyone see this
problem?
--Kazu
Hi Mateusz,
I'll try building now. What's the error?
Not building but validate. validate stops due to an error from
haddock in the xhtml library.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Hi Austin,
It seems to me that the patch for Cabal in ticket 8266 is still missing:
https://ghc.haskell.org/trac/ghc/ticket/8266
diff --git a/Cabal/Distribution/Simple/GHC.hs b/Cabal/Distribution/Simple/GHC.hs
index c7ea633..78cdcbb 100644
--- a/Cabal/Distribution/Simple/GHC.hs
+++
Hello Herbert,
Hello Kazu,
..as this is a Cabal issue, this needs to be handled upstream; could you
please file an issue at
https://github.com/haskell/cabal/issues/new
Done.
https://github.com/haskell/cabal/issues/1660
--Kazu
___
Hi,
Let me know if there are any questions or more importantly if I've
missed anything.
Please don't forget #8266. One patch should be applied to Cabal lib.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi Austin,
The RC2 source distribution is here:
http://www.haskell.org/ghc/dist/7.8.1-rc2/
To my quick test, the @rpath problem on Mac has been fixed.
Thank you!
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi Austin,
We've closed approximately 45 tickets that people filed for RC1 in
this release. Thank you for all the reports!
Good work!
We plan to make the final 7.8.1 release soon, and hope RC2 will be the
last RC. So *please* test as much as possible; bugs are much cheaper
if we find them
Hi,
The tests for doctest are not passed again with GHC 7.8:
17) Property.runProperty reports the values for which a property that takes
multiple arguments fails
expected: [False,0,\\]
but got: [interactive:24:66:,\8216doctest_prop\8217 is not in the
type environment at a reify,
Hi,
Adam told a solution which uses mkName:
https://github.com/sol/doctest-haskell/issues/76
Unfortunately, I hit upon another issue of Template Haskell.
I will ask a question in another mail.
--Kazu
Hi,
The tests for doctest are not passed again with GHC 7.8:
17)
Hi,
Yes: https://ghc.haskell.org/trac/ghc/ticket/8833
Austin is looking at this for the 7.8 release
Thanks. I guess you meant:
https://ghc.haskell.org/trac/ghc/ticket/8831
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Helo,
The 7.8.2 source tarball is here. I actually have most of the binaries
ready, but I forgot to send this in advance:
http://www.haskell.org/ghc/dist/7.8.2/
Please build when you get a chance. I'll probably go ahead and
announce shortly to get the bugfix into peoples hands, and we
Hi Herbert,
After a short conversion with Austin and Edward it appears that the
sensible course of action with respect towards moving to a proper Git
submodule set-up is to fold-in the 5 Git repos listed below (which btw
are all GHC wired-in packages) directly into ghc.git (the same way
Hi Herbert,
Thank you for your kind explanation!
--Kazu
Otoh, I can offer part of the motivation for using `git submodules` from
my current point of view from the top of my head:
- We already use Git submodules for half the sub-repos, using a mix of
submodules and subtrees might
Hi,
Many tests for validate on master fail on Mavericks. This is because clang
produces some warnings. Here is an example:
= AssocTyDef03(normal) 3519 of 3960 [0, 1649, 0]
cd ./typecheck/should_fail '/Users/kazu/work/ghc/bindisttest/install
dir/bin/ghc
' -fforce-recomp -dcore-lint
Richard,
I've posted this problem as #9047
(https://ghc.haskell.org/trac/ghc/ticket/9047), but I have no
information to help you -- sorry!
Thanks anyway.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
To test the coming GHC 7.8.3, I started to use the latest ghc-7.8
branch. Unfortunately, on my Mac, I saw many warnings which are not
displayed with GHC 7.8.2:
clang: warning: argument unused during compilation: '-fno-stack-protector'
clang: warning: argument unused during compilation: '-D
Hi,
Also I found that GHC 7.8.2 can compile yesod-bin but GHC 7.8.3
cannot:
[ 1 of 10] Compiling GhcBuild ( GhcBuild.hs,
dist/build/yesod/yesod-tmp/GhcBuild.o )
GhcBuild.hs:150:55:
Couldn't match type ‘Phase’ with ‘Bool - Phase’
Expected type: [(String, Maybe (Bool -
1 - 100 of 151 matches
Mail list logo
