Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/ghc/nightly/HEAD-cam-02-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Thu Jul 26 19:30:00 BST 2007.
checki
Thu Jul 26 11:16:22 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Fix building the HEAD with itself
M ./compat/Makefile +7
M ./compat/compat.mk +5
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Thu Jul 26 09:42:01 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Link with hpc even if GhcWithInterpreter is not set
M ./compiler/Makefile -2 +7
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On Jul 26, 2007, at 8:54 AM, Simon Marlow wrote:
Duncan Coutts wrote:
On Thu, 2007-07-26 at 08:53 +0100, Simon Marlow wrote:
The library route would be preferable, unless it causes any
licensing headaches.
LGPL'ed Haskell code can't be so easily relinked as C code (stable
ABI
and all that
Duncan Coutts wrote:
On Thu, 2007-07-26 at 08:53 +0100, Simon Marlow wrote:
Peter Tanski wrote:
StgCRun.S is done for x86 (still need to do x86_64 and ia64). Builds fine.
What about using cpphs with GHC? I could set it up as either a program
run by ghc for 'runCpp' or as a library called by
On Jul 26, 2007, at 9:37 AM, Peter Tanski wrote:
On Jul 26, 2007, at 7:02 AM, Neil Mitchell wrote:
I haven't tried, but doesn't this already work if you set the CPP
environment variable to cpphs before running configure? You might
also
need to set CPPFLAGS to something.
If you pass the --c
On Jul 26, 2007, at 7:02 AM, Neil Mitchell wrote:
I haven't tried, but doesn't this already work if you set the CPP
environment variable to cpphs before running configure? You might
also
need to set CPPFLAGS to something.
If you pass the --cpp flag then cpphs works like GHC expects,
otherwi
Hi
I have some misgivings about whether linking LGPL Haskell libraries is
within the spirit of the license, given that re-linking is often
impractical. But nobody else seems to care about this, I haven't seen any
authors of Haskell LGPL libraries complain that users can't easily comply
with it.
Hi Thorkil,
On Thu, Jul 26, 2007 at 12:28:22PM +0200, Thorkil Naur wrote:
>
> The tnaur PPC OSX builder still fails with
>
> > rm -f base/GNUmakefile
> > cp Makefile.local base
> > ifBuildable/ifBuildable base setup/Setup makefile -f GNUmakefile
> > Setup: Errors:
> > unexpected argument: GNUma
Simon Marlow wrote:
> Is this perhaps related to the following comment in TailCalls.h?
It looks as though it might be the same bug. No response yet from the
gcc maintainers, we'll see whether it gets fixed.
--
Joe Buehler
___
Cvs-ghc mailing list
Cvs
Hi
I haven't tried, but doesn't this already work if you set the CPP
environment variable to cpphs before running configure? You might also
need to set CPPFLAGS to something.
If you pass the --cpp flag then cpphs works like GHC expects,
otherwise it has a different set of flags.
Thanks
Neil
On Wed, Jul 25, 2007 at 03:19:39PM -0400, Peter Tanski wrote:
> StgCRun.S is done for x86 (still need to do x86_64 and ia64). Builds
> fine.
>
> What about using cpphs with GHC? I could set it up as either a
> program run by ghc for 'runCpp' or as a library called by runCpp.
I haven't tried
On Thu, 2007-07-26 at 08:53 +0100, Simon Marlow wrote:
> Peter Tanski wrote:
> > StgCRun.S is done for x86 (still need to do x86_64 and ia64). Builds fine.
> >
> > What about using cpphs with GHC? I could set it up as either a program
> > run by ghc for 'runCpp' or as a library called by runCpp
Hello Ian,
The tnaur PPC OSX builder still fails with
> rm -f base/GNUmakefile
> cp Makefile.local base
> ifBuildable/ifBuildable base setup/Setup makefile -f GNUmakefile
> Setup: Errors:
> unexpected argument: GNUmakefile
> make[1]: *** [base/GNUmakefile] Error 1
> make: *** [stage1] Error 2
> p
Thu Jul 26 02:40:30 PDT 2007 Simon Marlow <[EMAIL PROTECTED]>
* Documentation updates for #1177
We now have a section that describes what hs_exit() does (including
the "wait for foreign calls to return" behaviour), and more
documentation on creating libraries of Haskell code. I also impor
Hello,
On Thursday 26 July 2007 09:56, Simon Marlow wrote:
> Thorkil Naur wrote:
>
> > There is still the question of whether the 1 second delay should be
considered
> > excessive, but I will leave that for others to decide.
>
> I'd like to bring this test back into 'make fast' and hence valid
Wed Jul 25 19:45:51 PDT 2007 Roman Leshchinskiy <[EMAIL PROTECTED]>
* PA instance generation code (not used yet)
M ./compiler/vectorise/VectType.hs -6 +34
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-gh
Tue Jul 24 19:30:17 PDT 2007 Roman Leshchinskiy <[EMAIL PROTECTED]>
* More refactoring
M ./compiler/vectorise/VectUtils.hs -1 +9
M ./compiler/vectorise/Vectorise.hs -9 +5
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mai
Wed Jul 25 20:12:47 PDT 2007 Roman Leshchinskiy <[EMAIL PROTECTED]>
* Use the right dictionary when calling lengthPA
M ./compiler/vectorise/VectUtils.hs -2 +15
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/c
Tue Jul 24 21:12:42 PDT 2007 Roman Leshchinskiy <[EMAIL PROTECTED]>
* PA dictionary generation
M ./compiler/vectorise/VectMonad.hs -1 +4
M ./compiler/vectorise/VectType.hs -4 +31
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell
Wed Jul 25 22:22:39 PDT 2007 Roman Leshchinskiy <[EMAIL PROTECTED]>
* Make sure DEFAULT always comes first in generated PA dictionaries
M ./compiler/vectorise/VectType.hs -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/m
Wed Jul 25 22:28:30 PDT 2007 Roman Leshchinskiy <[EMAIL PROTECTED]>
* Add missing coercion
M ./compiler/vectorise/VectType.hs -4 +6
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Thorkil Naur wrote:
There is still the question of whether the 1 second delay should be considered
excessive, but I will leave that for others to decide.
I'd like to bring this test back into 'make fast' and hence validate, since
it has caught several bugs recently. On my x86_64/Linux system
Peter Tanski wrote:
StgCRun.S is done for x86 (still need to do x86_64 and ia64). Builds fine.
What about using cpphs with GHC? I could set it up as either a program
run by ghc for 'runCpp' or as a library called by runCpp.
We've avoided cpphs so far because of the license. But if there's
Hello,
On Wednesday 25 July 2007 11:30, Simon Marlow wrote:
> ...
> Thorkil: I read your discussion with Igloo on #ghc last night, and I found
> one bug in GHC/Handle.hs as a result. We should be allocating the Handle
> buffer pinned now that it can be passed to "safe" foreign calls in the
> t
Build results:
x86-64 Linux head: pass
x86 Windows head: pass
x86 Windows head fast: fail (failed stage1) pass pass pass pass pass
gbesh Intel x86_64 Linux head: pass
kahl G5 Gentoo Linux head: fail (failed stage1)
mnemosyne x86-64 Gentoo head: pass
tnaur PPC O
Wed Jul 25 22:21:08 PDT 2007 Roman Leshchinskiy <[EMAIL PROTECTED]>
* Fix generation of lengthPA
M ./compiler/vectorise/VectMonad.hs -1 +4
M ./compiler/vectorise/VectType.hs -6 +9
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskel
27 matches
Mail list logo
