-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
test!
- --
Eray Ozkural (exa) <[EMAIL PROTECTED]>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C
-BEGIN PGP SIG
please ignore
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
test
text.zip
Description: Binary data
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I've got the 'welcome' message:
Welcome to the glasgow-haskell-users mailing list!
Please save this message for future reference. Thank you.
but no post and its been over a month.
is the list dead?
___
Glasgow-haskell-users mailing list
[EMAIL
I tested ghc-pre-4.07 on my large algebraic program. It works.
--
Sergey Mechveliani
[EMAIL PROTECTED]
Dear ghc-5.00.1 (binary, linux, i386-unknown),
Here are some information on performance that may occur useful.
Choose n, run test n in various modes and compare the timings.
It consists mainly of merge sorting of a list of Int-s combined
with reversing.
The particular points I find are
Dear GHC developers,
I have tested ghc-6.10.3.20090628
on Debian Linux, i-386-kind machine.
There were only two tests:
1) making from source by itself
2) making DoCon and running its test (without profiling).
It looks all right.
With kind regards,
-
Serge Mechveliani
mech
version of the
compiler, and running it with
SKIPWAY="optc profc optllvm" fast=YES
I get this result:
OVERALL SUMMARY for test run started at Sa 7. Jan 17:45:54 CET 2012
2612 total tests, which gave rise to
10986 test cases, of which
0 caused framework failures
About the 6.8.3 candidate of May 27,
there remains the question:
why it builds DoCon-2.11 considerably slower than ghc-6.8.2
(3 times, as I recall)
and needs larger -M memory to build this DoCon
?
Regards,
-
Serge Mechveliani
[EMAIL PROTECTED]
Dear GHC developers,
I wonder: why do not you use the DoCon program as the test?
For many years, an attempt
to build DoCon according to install.txt
and to run its test .../demotest/T_
reveals on average a couple of serious bugs in a new GHC version.
One does not need to study
On Mon, Jul 06, 2009 at 10:12:21PM +0400, Serge D. Mechveliani wrote:
>
> I have tested ghc-6.10.3.20090628
> on Debian Linux, i-386-kind machine.
> There were only two tests:
> 1) making from source by itself
> 2) making DoCon and running its test (without profiling).
&g
the released testsuite for 7.0.4 with that version of the
compiler, and running it with
SKIPWAY="optc profc optllvm" fast=YES
I get this result:
OVERALL SUMMARY for test run started at Sa 7. Jan 17:45:54 CET 2012
2612 total tests, which gave rise to
10986 test cases
If you build GHC with just the default settings, QuickCheck doesn't get pulled from Darcs and it is thus not built and installed into ghc-inplace. Because of this, many of the tests in the test suite fail:SampleVar001
Chan001MVar001QSemN001QSem001bytestring001bytestring004bytestring005I think
> I wonder: why do not you use the DoCon program as the test?
No deep reasons, but DoCon is a *lot* of code to include in our nightly
builds. Perhaps we should have a large lump of infrequently-run tests,
including things like DoCon.
Cheers,
Si
I fired up the new codegen and ran make fast on the regression suite
and the following new tests started failing:
3207(normal)
4030(normal)
cgrun016(normal)
cgrun045(normal)
cgrun051(normal)
dsrun005(normal)
dsrun007(normal)
dsrun008(normal)
exceptionsrun001(normal)
e
After further review, I can see that the test suite also requires 'network,' 'html,' and 'mtl' for all the tests to pass.Maybe we need to separate the packages into three groups: core, tests, and extras, where all the packages required by the test suite would
On Wed, 2006-09-13 at 01:17 -0500, Brian Smith wrote:
> After further review, I can see that the test suite also requires
> 'network,' 'html,' and 'mtl' for all the tests to pass.
>
> Maybe we need to separate the packages into three groups: core, t
Hi,
when running the test-suite I get plenty of the link errors (below).
In order to resolve the missing symbols in Printer.thr_debug_o I was
able to add
-optl-L/usr/local/lib -optl-lbfd -optl-liberty
to the ghc-6.6 command line. Note that "-L/usr/local/lib" is necessary,
because oth
Hi,
I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as
an official installer, could people please test it?
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe
The new features of this installer (relative to the 6.6 one) are:
* Prettier .hs
I've put up an x86_64/Linux registerised build for testing here:
http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4-x86_64-unknown-linux
.tar.bz2
This is a binary distribution: ./configure && make -k install. The -k
is necessary because it doesn't have all the docs. It was built on
Fedora F
Hi, I did a test build [1] of the current ghc-7.8 branch for Fedora 21
devel,
which I think should also install to Fedora 20.
I put the packages for x86_64, i386 and armv7hl into the yum repos under
http://repos.fedorapeople.org/repos/petersen/ghc-7.7/
I haven't tested this latest build ye
Which branch are you working off though? ghc HEAD doesn't have the
latest changes to the new codegen, afaik the latest changes are in the
branch
http://darcs.haskell.org/ghc-cmm-03Sep10/
There is also a branch now though at
http://darcs.haskell.org/ghc-new-co-17Nov10/ which I'm not sure what
it r
I'm working off HEAD, so this is good info to know.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Excerpts from David Terei's message of Fri Dec 03 23:44:33 -0500 2010:
> http://darcs.haskell.org/ghc-cmm-03Sep10/
This branch fails to build for me:
"inplace/bin/ghc-stage1" -M -dep-makefile
libraries/dph/dph-par/dist-install/build/.depend-v.haskell.tmp
-include-pkg-deps -H64m -O -fasm -packa
I get the same error for the other branch too.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
When I revert the PArr -> ParallelArray changes in those directories,
I then get:
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.1.20101126 for i386-unknown-linux):
match_co
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Gla
On Sat, Dec 04, 2010 at 03:44:33PM +1100, David Terei wrote:
>
> There is also a branch now though at
> http://darcs.haskell.org/ghc-new-co-17Nov10/ which I'm not sure what
> it relates to, so check that out as well or wait for someone who knows
> for sure to respond.
This branch contains a refac
Oh, that explains the co error! Thanks a bunch.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I haven't looked at these branches for a fair few weeks, the problem
when they fail to build usually is because all the libraries are just
set to follow HEAD, they're not actually branched themselves, just the
ghc compiler. So there are probably some patches from ghc HEAD that
need to be pulled in
On 06/12/2010, at 1:19 PM, David Terei wrote:
> I haven't looked at these branches for a fair few weeks, the problem
> when they fail to build usually is because all the libraries are just
> set to follow HEAD, they're not actually branched themselves, just the
> ghc compiler. So there are probab
I did a bit more merging of your branch. My current state is here:
http://darcs.haskell.org/ghc-cmm-15Sep10/
it doesn't actually build, but the failure is somewhere in hoopl I
think. This branch is 400-odd patches behind the current HEAD. I don't
think I borked anything too badly during the
I've done a bit more chewing away at the branch and have gotten to
19Sep10.
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ian, I'd love a little guidance with this patch:
Thu Oct 21 13:08:53 BST 2010 Ian Lynagh
* Use takeUniqFromSupply in emitProcWithConvention
We were using the supply's unique, and then passing the same supply to
initUs_, which sounds like a bug waiting to happen.
{
hunk ./compiler/c
Final status report for tonight, before I crash in bed;
I've managed to make it compile all the way to hoopl.
It seems like hoopl doesn't typecheck anymore? I haven't
been following the typechecker changes too closely so
some guidance would be appreciated.
libraries/hoopl/src/Compiler/Hoopl/Util.h
On 09/12/2010 04:42, Edward Z. Yang wrote:
Final status report for tonight, before I crash in bed;
I've managed to make it compile all the way to hoopl.
It seems like hoopl doesn't typecheck anymore? I haven't
been following the typechecker changes too closely so
some guidance would be appreciate
On Wed, Dec 08, 2010 at 11:31:19PM -0500, Edward Z. Yang wrote:
> Ian, I'd love a little guidance with this patch:
>
> Thu Oct 21 13:08:53 BST 2010 Ian Lynagh
> * Use takeUniqFromSupply in emitProcWithConvention
> We were using the supply's unique, and then passing the same supply to
> ini
Here is the new set of failing test-cases on the shiny new branch.
I should stick the merged branch somewhere; any suggestions?
4030(normal)
4221(normal)
IndTypesPerf(normal)
T1969(normal)
T3064(normal)
T3294(normal)
T3736(normal)
T3807(normal)
T4003(normal
-bit x86
when entering _info blocks?)
0x822a6e0 : jmp0x822a620
0x822a620 : mov0x4(%esi),%eax
0x822a623 :test $0x3,%eax
0x822a628 :jne0x822a663
0x822a62a : mov(%eax),%ecx -- SEGFAULT!
Registers right at the segfault:
eax0x0
Ok, I've got a patch that fixes this segfault. In the process I looked
at all patches to Cg* modules after Nov 2009 and looked for changes that
weren't applied to the new codegen. I skipped the LLVM patch, but picked
up the rest of the blackhole changes. There are, however, two hunks that
I am n
Hello Simon,
Have you gotten a chance to look at these two hunks? (see below)
Thanks,
Edward
Excerpts from Edward Z. Yang's message of Fri Dec 10 10:59:26 -0500 2010:
> Ok, I've got a patch that fixes this segfault. In the process I looked
> at all patches to Cg* modules after Nov 2009 and look
I appear to have tracked down the bug for ffi021: the new
code generator doesn't appear to clear the tag bit for the
pointer to heap before:
// outOfLine should follow:
(_sR1::I32,) = foreign "ccall"
_sQR::I32((I32[_sRi::I32 + 7], `signed'),
(I32[_sRi
With further poking, I think the new codegen is actually tickling
an existing bug in the native code generator optimizations, since
the cmmz output looks ok:
cSH:
_sQR::I32 = I32[_sRi::I32 + 3]; // CmmAssign
_sQS::I32 = I32[_sRi::I32 + 7]; // CmmAssign
_sQT:
I think the bug might be here:
inlineStmt u a (CmmCall target regs es srt ret)
= CmmCall (infn target) regs es' srt ret
where infn (CmmCallee fn cconv) = CmmCallee fn cconv
infn (CmmPrim p) = CmmPrim p
es' = [ (CmmHinted (inlineExpr u a e) hint) | (CmmHinted e hint) <- es
Yep, switching
> inlineStmt u a (CmmCall target regs es srt ret)
> = CmmCall (infn target) regs es' srt ret
> where infn (CmmCallee fn cconv) = CmmCallee fn cconv
> infn (CmmPrim p) = CmmPrim p
> es' = [ (CmmHinted (inlineExpr u a e) hint) | (CmmHinted e hint) <- es
to
> inline
On 13/01/2011 12:51, Edward Z. Yang wrote:
Yep, switching
inlineStmt u a (CmmCall target regs es srt ret)
= CmmCall (infn target) regs es' srt ret
where infn (CmmCallee fn cconv) = CmmCallee fn cconv
infn (CmmPrim p) = CmmPrim p
es' = [ (CmmHinted (inlineExpr u a e) hint)
Ok, I have a stage2 compiler built with the new codegen all
the way, and here are the new failing cases:
1372(normal)
2047(normal)
4030(normal)
OldException001(normal)
async001(normal)
bug1465(normal)
cabal01(normal)
cabal03(normal)
cgrun016(normal)
cgrun045(normal)
it's in some library (but
then why is it affected by optimizations?). Can I easily get C-- dumps of all
the librarise?
I suspect that I should actually do the full (and not just fast) test suite
on the stage2-new-codegen build to squirrel out more of these optimization
bugs, since debugging
y is already compiled. You can grep for the
symbol in the library .o files, and then compile the offending module
with -ddump-cmm (the symbol name might change, so you might have to
recompile and debug the program again to get the new symbol name).
Cheers,
Simon
I suspect th
o let testing continue. I'm not sure, though.
OVERALL SUMMARY for test run started at Sun Jul 9 19:02:59 BST 2006
1090 total tests, which gave rise to
4985 test cases, of which
13 caused framework failures
1003 were skipped
3460 expected passes
22 expected failure
Hello Brian,
Wednesday, September 13, 2006, 10:17:10 AM, you wrote:
> Maybe we need to separate the packages into three groups: core,
> tests, and extras, where all the packages required by the test suite
> would get put into the "tests" group?
or core, ghc-for-g
Christian Maeder schrieb:
> Hi,
>
> when running the test-suite I get plenty of the link errors (below).
> In order to resolve the missing symbols in Printer.thr_debug_o I was
> able to add
>
> -optl-L/usr/local/lib -optl-lbfd -optl-liberty
>
> to the ghc-6.6 command
Neil Mitchell wrote:
Hi,
I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as
an official installer, could people please test it?
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe
Thanks Neil,
This works perfectly!
Best regards,
Neil Mitchell wrote:
Hi,
I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as
an official installer, could people please test it?
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe
Thanks for that. It seems to install and compile the collections
pa
Hi Neil,
On Tue, 08 May 2007 00:34:10 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as
> an official installer, could people please test it?
>
> http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386
Hi
You forgot to include GLUT and readline packages.
I think you can't build these packages, so you don't include it.
I have built an installer for the binary package produced by the GHC
Team, including whatever they included, and excluding whatever they
excluded. If the GHC Team change their
On Tue, 08 May 2007 19:04:33 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote:
>> You forgot to include GLUT and readline packages.
>> I think you can't build these packages, so you don't include it.
>
> I have built an installer for the binary package produced by the GHC
> Team, including whatever t
Hi
So I want to know "What version of MinGW do you use?" and "Is your
MinGW has C++ files?"
None, I don't have it installed. I took the binaries straight from the
GHC 6.6.1 .tar.bz on haskell.org, I guess Ian would know how they
build that.
I think these tasks are easy, and they don't become
pipermail/glasgow-haskell-users/2007-April/thread.html#12408
The reason I didn't enable C++ support in prep-bin-dist-mingw is because of that
comment, and because I don't know how to test it. Basically I chickened out.
Are you saying it should just be uncommented in prep-bin-dist-mingw?
shelarcy wrote:
> GHC 6.6's installer (MSI) has three Installation Mode, Typical,
> Custom, Complete. These mode doesn't work GHC 6.6's one, but some
> other installer uses these Installation Mode, to suport install
> options.
Custom/complete: yes, typical: no. What on earth does "typical" mean
Hi
> GHC 6.6's installer (MSI) has three Installation Mode, Typical,
> Custom, Complete. These mode doesn't work GHC 6.6's one, but some
> other installer uses these Installation Mode, to suport install
> options.
Custom/complete: yes, typical: no. What on earth does "typical" mean? The
user
code by GHC, he disappoint
>> about that.
>>
>> http://hackage.haskell.org/trac/ghc/ticket/1024
>> http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/thread.html#12408
>
> The reason I didn't enable C++ support in prep-bin-dist-mingw is because o
On Wed, 09 May 2007 17:31:51 +0900, Simon Marlow <[EMAIL PROTECTED]> wrote:
>> You forgot to include GLUT and readline packages.
>> I think you can't build these packages, so you don't include it.
>>
>> This is well-known problem, if build GHC your self.
>> Because MInGW doesn't have these headers
On Wed, 09 May 2007 17:42:11 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote:
>> Custom/complete: yes, typical: no. What on earth does "typical" mean? The
>> user has no idea whether it will install the features they need or not, so
>> it's
>> a meaningless option.
>
> From all I can tell, GHC 6
shelarcy wrote:
> Hi,
>
> On Wed, 09 May 2007 17:31:51 +0900, Simon Marlow <[EMAIL PROTECTED]> wrote:
>> So to summarise, the following are missing from the binary distribution that
>> Neil used as the basis for his installer:
>>
>> * readline
>> * ALUT
>> * OpenAL
>> * GLUT
>> * C++ sup
Hi
I don't have InstallerShield, so I don't fix its problem.
But Inno Setup is OpenSource, so, although Neil doesn't fix this problem
on current time, we can fix this (Of cource, installer's source must be
available).
I've attached the installer source to this message, for you to play
with/pat
Hi
On Thu, 10 May 2007 18:36:22 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> I've attached the installer source to this message, for you to play
> with/patch to your hearts content. I sent a copy to Ian a few days, so
> it should be appearing in the GHC tree at some point.
I succeed to build
On Thu, 10 May 2007 18:11:52 +0900, Simon Marlow <[EMAIL PROTECTED]> wrote:
>>> So to summarise, the following are missing from the binary distribution that
>>> Neil used as the basis for his installer:
>>>
>>> (snip)
>>>
>>> right?
>>
>> Yes. And Sigbjorn's one provides these packages.
>
> Ok, b
shelarcy wrote:
> Hi
>
> On Thu, 10 May 2007 18:36:22 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote:
>> I've attached the installer source to this message, for you to play
>> with/patch to your hearts content. I sent a copy to Ian a few days, so
>> it should be appearing in the GHC tree at some p
Simon Marlow wrote:
> shelarcy wrote:
>> Hi
>>
>> On Thu, 10 May 2007 18:36:22 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote:
>>> I've attached the installer source to this message, for you to play
>>> with/patch to your hearts content. I sent a copy to Ian a few days, so
>>> it should be appearin
Hi
> Ok, I'm building a new tarball with GLUT and C++. The OpenAL/ALUT stuff
looks a
> bit daunting at the moment. If someone tells me exactly what I need to
install
> to make it work, then I'll do that.
This tarball has GLUT and C++:
http://haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-unkno
Hi.
On Sat, 12 May 2007 00:44:15 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote:
>> > Ok, I'm building a new tarball with GLUT and C++. The OpenAL/ALUT stuff
>> > looks a
>> > bit daunting at the moment. If someone tells me exactly what I need to
>> > install
>> > to make it work, then I'll do
There's a test InstallShield for Windows of GHC 5.01 now available at
http://www.haskell.org/ghc/dist/5.00.2/ghc-5-01.exe
There is no link to this from the web pages, as it's not intended for
general consumption.
This is a thrill-seekers' release (hence the moniker). Please do
On Tue, 2005-03-08 at 15:16 +, Simon Marlow wrote:
> I've put up an x86_64/Linux registerised build for testing here:
>
>
> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4-x86_64-unknown-linux
> .tar.bz2
>
> This is a binary distribution: ./configure && make -k install. The -k
> is nec
On 08 March 2005 15:59, Duncan Coutts wrote:
> On Tue, 2005-03-08 at 15:16 +, Simon Marlow wrote:
>> I've put up an x86_64/Linux registerised build for testing here:
>>
>>
>>
http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4-x86_64-unknown-linux
>> .tar.bz2
>>
>> This is a binary distrib
Simon Marlow ([EMAIL PROTECTED]) wrote:
Hi Simon!
> I've put up an x86_64/Linux registerised build for testing here:
Thank you very much.
> This is a binary distribution: ./configure && make -k install. The -k
> is necessary because it doesn't have all the docs. It was built on
> Fedora FC3.
Hi Simon,
this is just to let you know that I successfully compiled the lastest
snapshot (ghc-6.4.20050308). Initial tests look promising. Thanks!
Cheers, Ralf
PS: Just curious: is the gcc route easier than the NCG? To me it seems
much more fragile.
__
On 09 March 2005 10:14, Ralf Hinze wrote:
> this is just to let you know that I successfully compiled the lastest
> snapshot (ghc-6.4.20050308). Initial tests look promising. Thanks!
>
> Cheers, Ralf
>
> PS: Just curious: is the gcc route easier than the NCG? To me it seems
> much more fragile.
Dear Jens,
Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen:
> Hi, I did a test build [1] of the current ghc-7.8 branch for Fedora 21
> devel,
> which I think should also install to Fedora 20.
I’m surprised that it worked for you. Did not you not hit
http://ghc.haskell.org
Hi Joachim,
> Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen:
> > Hi, I did a test build [1] of the current ghc-7.8 branch for Fedora 21
> > devel, which I think should also install to Fedora 20.
>
> I’m surprised that it worked for you. Did not you not hit
>
Hi,
Am Dienstag, den 04.02.2014, 09:52 +0900 schrieb Jens Petersen:
> Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen:
> > Hi, I did a test build [1] of the current ghc-7.8 branch for
> Fedora 21
> > devel, which I think should also
Hi,
Am Dienstag, den 04.02.2014, 09:03 + schrieb Joachim Breitner:
> Am Dienstag, den 04.02.2014, 09:52 +0900 schrieb Jens Petersen:
>
> > Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen:
> > > Hi, I did a test build [1] of the curre
I wrote today on testing of ghc-6.4.1-July-12-2005
> 3. Memory test with loading to ghci the whole DoCon test
> (DoCon compiled with -O, tests compiled with -Onot)
> and performing it:
> 6.4.1-July-12 needs the minimum of 18 Mb,
> 6.4, 6.4.1-June-14 need
got hung and
> I had to Ctrl-C them to let testing continue. I'm not sure, though.
>
> OVERALL SUMMARY for test run started at Sun Jul 9 19:02:59 BST 2006
> 1090 total tests, which gave rise to
> 4985 test cases, of which
> 13 caused framework failures
>
the framework failures were cases where tests got hung and
> > I had to Ctrl-C them to let testing continue. I'm not sure, though.
> >
> > OVERALL SUMMARY for test run started at Sun Jul 9 19:02:59 BST 2006
> > 1090 total tests, which gave rise to
> >
On Jul 10, 2006, at 2:29 PM, Donald Bruce Stewart wrote:
Using the wrong stage for the test? You'll need to use the stage2 ghc.
How do I do this?
I just ran make in the tests directory and it indeed picked up stage1
ghc.
Thanks, Joel
--
http://wagerlab
On Jul 10, 2006, at 2:29 PM, Donald Bruce Stewart wrote:
Using the wrong stage for the test? You'll need to use the stage2 ghc.
make stage=2 does it but I wish this was documented.
--
http://wagerlabs.com/
___
Glasgow-haskell-users ma
Joel Reymont wrote:
On Jul 10, 2006, at 2:29 PM, Donald Bruce Stewart wrote:
Using the wrong stage for the test? You'll need to use the stage2 ghc.
make stage=2 does it but I wish this was documented.
wish granted :-)
Simon
___
Glasgow-ha
This is using stage2. Does it look any better?
OVERALL SUMMARY for test run started at Mon Jul 10 15:11:22 BST 2006
952 total tests, which gave rise to
4583 test cases, of which
11 caused framework failures
1099 were skipped
3185 expected passes
24 expected failures
joelr1:
> This is using stage2. Does it look any better?
>
> OVERALL SUMMARY for test run started at Mon Jul 10 15:11:22 BST 2006
> 952 total tests, which gave rise to
> 4583 test cases, of which
> 11 caused framework failures
> 1099 were skipped
>
&g
It's a little bit more complicated for me since some tests just plain
hang. I will investigate, though.
On Jul 11, 2006, at 2:56 AM, Donald Bruce Stewart wrote:
Not too bad (mips64 is around the same), but not the same as the
linux head:
[...]
So the next step would be to diff the two resul
Joel Reymont wrote:
It's a little bit more complicated for me since some tests just plain
hang. I will investigate, though.
Which ones hang? Could you take one of the hanging tests, compile it with
-debug, run with +RTS -Ds, and send us the output?
Cheers,
Simon
___
d_fail && '/Users/joelr/work/Haskell/ghc/compiler/stage2/ghc-
inplace' -no-recomp -dcore-lint -dcmm-lint -Di386_apple_darwin -c
tcfail011.hs>tcfail011.comp.stderr 2>&1
Now, these things have been running there forever and I'm not even
sure it's a Haskell pro
cd ./typecheck/
should_fail && '/Users/joelr/work/Haskell/ghc/compiler/stage2/ghc-
inplace' -no-recomp -dcore-lint -dcmm-lint -Di386_apple_darwin -c
tcfail011.hs>tcfail011.comp.stderr 2>&1
Now, these things have been running there forever and I'm not even su
Here's my first feedback concerning GHC 5.01 for Win:
There are significant improvements of compilation speed (about 20% faster, sometimes
even more) and the generated code's size (about 40% smaller). And the new "--make"
option and GHCi are really great features!
However, I already discovered
> - The included version of HaXml (including dtdtohaskell.exe etc.) is not
> up-to-date.
That's up to HaXml's author, Malcolm Wallace. The InstallShield shipped with
the latest version from CVS. (Malcolm, could you possibly update, please?)
> - When leaving out the "-o" option, GHC4.08.2 default
Hi @ll,
I'd like to tell you about a small script I've written to make life
easier with git:
git clone git://mawercer.de/git-test-merge
It remembers test merge setups so that you can merge different feature
branches by typing:
$ gtm set setup1 branch1 remotes/branc
gain.
>>>>
>>>> If you're on 10.9, you'll need to use recent GHC head +
>>>> CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI
>>>> tools may have all the needed clang patches, but thats
>&g
iOS patch!
>>>>> Cheers
>>>>> Luke
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald
>>>>> >>>>
>>>>> <mailto:carter.s
t 5:29 PM, Luke Iannini <
>>>>>> lukex...@gmail.com
>>>>>> <mailto:lukex...@gmail.com>> wrote:
>>>>>>
>>>>>> Update: I've got GHC HEAD building on 10.9 again, tonight
>>>>>> I'll dive
w LLVM 3.4 only
>>>>>>> includes host platforms by default (x86/x86-64)
>>>>>>> Reinstalling it with all-targets enables them all:
>>>>>>> brew install llvm --with-clang --all-targets --HEAD
&
1 - 100 of 104 matches
Mail list logo
