headers
Simon Marlow | 1 Aug 2005 14:00
Picon
Favicon

RE: Installation problem

On 30 July 2005 12:58, Dieter wrote:

> I'm using Linux 9.3 on a PC with a 64-architecture.
> 
> I'd like to install GHC and thought the easiest way would be to take
> an appropriate rpm-file.So I downloaded an rpm file, it was said to
> running with SUSE 9.2 without problems.
> But when starting rpm -i ghc.-6.4-1.i386.rpm I got the message:
> 
> error: Failed dependencies:
>           libgmp.so.3 is needed by ghc-6.4-1
> 
> But it is installed on my systems. I downloaded it again and
> installed it again and copied it (3 files: - the symlink libgmp.so,
> the symlink libgmp.so.3 and the file the libgmp.so.3.3.3) into
> several lib directories. NO SUCCESS
> 
> What is wrong?
> Has anyone an idea?

Are you running an x86_64 OS, or just a plain i386 one?  

If you're running x86_64, then perhaps you only have the 64-bit version
of libgmp installed?

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Simon Marlow | 1 Aug 2005 14:02
Picon
Favicon

RE: Bug in placing _stub.o files with HEAD

On 30 July 2005 01:21, Einar Karttunen wrote:

> I noticed the following behaviour using GHC 6.5.20050728:
> If compiling a Cabal package containing hs-source-dirs it
> places the _stub.o under dist/build/≤source-dir>/path/to/Module
> when Cabal expects it in dist/build/path/to/Module. Things
> appear to work without hs-source-dirs.
> 
> For example with "hs-source-dirs: src"
> Network/GnuTLS/IOWrap.hs contains foreign export declarations.
> runnning Setup build creates the files:
> dist/build/src/Network/GnuTLS/IOWrap_stub.o
> src/Network/GnuTLS/IOWrap_stub.h
> src/Network/GnuTLS/IOWrap_stub.c
> 
> But Cabal fails to include the IOWrap_stub.o as it is
> expected as dist/build/Network/GnuTLS/IOWrap_stub.o

I thought I fixed this in CVS recently (rev. 1.54 of
Distribution.Simple.Build to be exact).  Are you running Cabal from CVS,
or some other version?

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Simon Marlow | 1 Aug 2005 14:13
Picon
Favicon

RE: C--

On 31 July 2005 08:10, Bulat Ziganshin wrote:

> can you please say about value of using C-- in GHC? will this
> reduce compile time, increase speed of compiled programs, improve
> portability or make some other effect? would the C-- compile path
> replace asm or C path?

It should reduce compile time compared to compiling via C, though I
suspect it will still be slower than using GHC's built-in native code
generator.

It should improve the speed of compiled programs, because C-- will be
using its own, efficient, calling convention.  For example, this will
mean that some arguments can be passed in registers on x86, which we
can't do currently because of a combination of the lack of registers and
limitations in what we can convince gcc to do.

It should improve portability, because there is less work in GHC
required to compile via C-- on a new platform: no mangler to modify, for
example.

Eventually, we hope the registerised via-C path would become redundant.
The unregisterised path is still useful for bootstrapping, given that
more platforms have a C compiler than a C-- compiler (if C-- were to
become ubiquitous, the unregisterised path would become irrelevant too).

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Bulat Ziganshin | 1 Aug 2005 15:24

Re[2]: C--

Hello Simon,

Monday, August 01, 2005, 4:13:16 PM, you wrote:

SM> On 31 July 2005 08:10, Bulat Ziganshin wrote:

>> can you please say about value of using C-- in GHC? will this

SM> It should reduce compile time compared to compiling via C, though I
SM> It should improve the speed of compiled programs, because C-- will be

great. and when this will be implemented?

--

-- 
Best regards,
 Bulat                            mailto:bulatz <at> HotPOP.com
Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2005 15:38
Picon
Favicon

RE: Re[2]: C--

On 01 August 2005 14:25, Bulat Ziganshin wrote:

> Monday, August 01, 2005, 4:13:16 PM, you wrote:
> 
>> On 31 July 2005 08:10, Bulat Ziganshin wrote:
> 
>>> can you please say about value of using C-- in GHC? will this
> 
>> It should reduce compile time compared to compiling via C, though I
>> It should improve the speed of compiled programs, because C-- will be
> 
> great. and when this will be implemented?

I'll let those who are implementing it answer that :-)

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2005 15:43
Picon
Favicon

RE: Performance week 25/6-29/6

Ok, we made some progress on performance last week, but there's still
plenty to do.  Here's a summary:

  - Simon PJ found an O(n^2) case in the simplifier that appears to
    be the cause of most, if not all, of the cases of GHC going out
    to lunch when compiling certain modules.  However, while testing
    the fix we discovered that it caused worse code to be generated
    for some programs, so we're still looking into this.

  - I added a hack in GHC's back end to do some lightweight buffering of
    the
Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2005 15:52
Picon
Favicon

RE: Performance week 25/6-29/6

[ duh, hit send by mistake, that's twice today :-( ]

Ok, we made some progress on performance last week, but there's still
plenty to do.  Here's a summary:

  - Simon PJ found an O(n^2) case in the simplifier that appears to
    be the cause of most, if not all, of the cases of GHC going out
    to lunch when compiling certain modules.  However, while testing
    the fix we discovered that it caused worse code to be generated
    for some programs, so we're still looking into this.

  - I added a hack in GHC's back end to do some lightweight buffering of
    the output, which results in about a 10% speedup in compilation
    time.  The C output was also using the full pretty printer, when
    it doesn't really need to do indentation.

  - I tweaked the garbage collector in a few places, to get some
    modest speedup.

  - A nasty space leak in the native code generator was found & fixed.
    The space usage of GHC in general remains worse than we'd like.

  - A few other minor optimisations were made in the compiler.

We plan to put the simplifier fix into 6.4.1, and the NCG space-leak fix
is already in.  The other fixes are a little too intrusive with 6.4.1
being so close, so we'll hold off on those (possibly for 6.4.2).

Cheers,
	Simon
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2005 16:07
Picon
Favicon

6.4.1 release candidate testing

This is to announce that testing for 6.4.1 has begun.  Snapshots from
20050730 onwards are release candidates - please test if you can.
Snapshots are available from here:

   http://www.haskell.org/ghc/dist/stable/dist/

we have source snapshots, and binaries for Linux/x86 (RH 9.1 era),
Linux/x86_64 (FC3 era), and Windows.

A *huge* number of fixes have gone in since 6.4.  Also, big news is that
Linux/x86_64 will have a new native code generator and GHCi support
(including Template Haskell), so we'd especially like to hear from
anyone that can test on Linux/x86_64.  The GHCi support isn't complete:
the interpreter can't currently handle FFI, and there are problems with
data references to shared libraries from dynamically-loaded .o files,
but otherwise it should be functional.

We're planning for a release in 1-2 weeks.  I'm going to be offline for
a while from mid-Aug, but hopefully we'll get the release out before
then.

Please remember to put the full version number in any bug report, and
happy testing!

Cheers,
	Simon
Permalink | Reply | 10 comments |
headers
Einar Karttunen | 1 Aug 2005 16:19
Picon
Picon
Favicon

Re: Bug in placing _stub.o files with HEAD

"Simon Marlow" <simonmar <at> microsoft.com> writes:
> I thought I fixed this in CVS recently (rev. 1.54 of
> Distribution.Simple.Build to be exact).  Are you running Cabal from CVS,
> or some other version?

Cabal from CVS. The versions are GHC 6.5.20050728 and Cabal-1.1.2.

I created a small Cabal package to demonstrate the problem.
http://www.cs.helsinki.fi/u/ekarttun/haskell/test-hs-source-dirs-w-fexp.tar.gz

The _stub.o file is not added into the static library.

- Einar Karttunen
Permalink | Reply | 0 comments |
headers
Konovalov, Vadim | 1 Aug 2005 17:13
Picon

problems building trhsx-0.2 with ghc-6.5.20050723

I built and installed ghc-6.5.20050723 on Linux from sources successfully,
and it looks quite normally-working.

I've stepped into a problem building trhsx from a package
haskell-src-exts-0.2.tar.gz with a quite unexpected (for me) message:

Preprocessing executables for trhsx-0.2...
Building trhsx-0.2...
hsSourceDirs: ["."]
Chasing modules from: Hsx.hs

Hsx.hs:6:7:
    Could not find module `Data.List':
      it is a member of package base-1.0, which is hidden

Lines in error is quite innocent-looking:
import Data.List (intersperse, isPrefixOf)

GHC version 6.4 builds that module okay.

Is that error is due to beta version of ghc-6.5.20050723, or I am
misunderstanding some configuration issues?

TIA,
Vadim.
Permalink | Reply | 1 comment |

Gmane