RE: integer-simple

2011-07-31 Thread Chris Dornan 
Hi all,

 

Just to be absolutely sure I rebuilt a simple-integer ghc 7/2/1-RC1 with
itself (GMP ed.) on CentOS 6 with my usual build.mk. Using it installed and
inplace, I see the same effect (this time with -v):

 

inplace/bin/ghc-stage2 -v --interactive

GHCi, version 7.2.0.20110728: http://www.haskell.org/ghc/  :? for help

Glasgow Haskell Compiler, Version 7.2.0.20110728, stage 2 booted by GHC
version 7.2.0.20110728

Using binary package database:
/home/apache/ghc-7.2.0.20110728/inplace/lib/package.conf.d/package.cache

wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-inplace

wired-in package integer-simple mapped to integer-simple-0.1.0.0-inplace

wired-in package base mapped to base-4.4.0.0-inplace

wired-in package rts mapped to builtin_rts

wired-in package template-haskell mapped to template-haskell-2.6.0.0-inplace

wired-in package dph-seq not found.

wired-in package dph-par not found.

Hsc static flags: -static

Loading package ghc-prim ... linking ... done.

Loading package integer-simple ... linking ... ghc-stage2:
/home/apache/ghc-7.2.0.20110728/libraries/integer-simple/dist-install/build/
HSinteger-simple-0.1.0.0.o: unknown symbol
`base_ControlziExceptionziBase_patError_info'

*** Deleting temp files:

Deleting:

*** Deleting temp dirs:

Deleting:

ghc-stage2: unable to load package `integer-simple'

 

Chris

 

From: Chris Dornan [mailto:ch...@chrisdornan.com] 
Sent: 30 July 2011 22:37
To: 'glasgow-haskell-users@haskell.org'
Subject: RE: integer-simple

 

Hi All,

 

I thought I may as well try the same experiment 7.2.1-RC1 on completely
different hardware (a network v-server running CentOS 5 with ghc-6.12.3
installed) and indeed:

 

ghci

GHCi, version 7.2.0.20110728: http://www.haskell.org/ghc/  :? for help

Loading package ghc-prim ... linking ... done.

Loading package integer-simple ... linking ... ghc:
/usr/local/ghc/7.2.0.20110728/lib/ghc-7.2.0.20110728/integer-simple-0.1.0.0/
HSinteger-simple-0.1.0.0.o: unknown symbol
`base_ControlziExceptionziBase_patError_info'

ghc: unable to load package `integer-simple'

 

This has to be the way I am configuring the build - as y'all can see I am
configuring with a non-standard prefix, but otherwise it is a case of a
clean build from virginal sources with the appended build.mk.

 

I think I am going to have to start looking at the failure mechanism.

 

Chris

 

snipety-snip

 

#

-

# A Sample build.mk

#

# Uncomment one of the following BuildFlavour settings to get the desired

# overall build type, and then tweak the options in the relevant section

# below.

 

# Uncomment one of these to select a build profile below:

 

# Full build with max optimisation (slow build)

#BuildFlavour = perf

 

# Fastest build (libs unoptimised):

BuildFlavour = quickest

 

# Fast build with optimised libraries:

#BuildFlavour = quick

 

# Profile the stage2 compiler:

#BuildFlavour = prof

 

# A development build, working on the stage 1 compiler:

#BuildFlavour = devel1

 

# A development build, working on the stage 2 compiler:

#BuildFlavour = devel2

 

GhcLibWays = v

 

#  1. A Performance/Distribution
build

 

ifeq $(BuildFlavour) perf

 

# perf matches the default settings, repeated here for comparison:

 

SRC_HC_OPTS = -O -H64m

GhcStage1HcOpts = -O -fasm

GhcStage2HcOpts = -O2 -fasm

GhcHcOpts   = -Rghc-timing

GhcLibHcOpts= -O2 -XGenerics

GhcLibWays += p

 

ifeq $(PlatformSupportsSharedLibs) YES

GhcLibWays += dyn

endif

 

endif

 

#  A Fast build
--

 

ifeq $(BuildFlavour) quickest

 

SRC_HC_OPTS= -H64m -O0 -fasm

GhcStage1HcOpts= -O -fasm

GhcStage2HcOpts= -O0 -fasm

GhcLibHcOpts   = -O0 -fasm

SplitObjs  = NO

HADDOCK_DOCS   = NO

BUILD_DOCBOOK_HTML = NO

BUILD_DOCBOOK_PS   = NO

BUILD_DOCBOOK_PDF  = NO

 

endif

 

#  A Fast build with optimised libs
--

 

ifeq $(BuildFlavour) quick

 

SRC_HC_OPTS= -H64m -O0 -fasm

GhcStage1HcOpts= -O -fasm

GhcStage2HcOpts= -O0 -fasm

GhcLibHcOpts   = -O -fasm

SplitObjs  = NO

HADDOCK_DOCS   = NO

BUILD_DOCBOOK_HTML = NO

BUILD_DOCBOOK_PS   = NO

BUILD_DOCBOOK_PDF  = NO

 

endif

 

#  Profile the stage2 compiler
---

 

ifeq $(BuildFlavour) prof

 

SRC_HC_OPTS= -H64m -O0 -fasm

GhcStage1HcOpts= -O -fasm

GhcStage2HcOpts= -O -fasm

GhcLibHcOpts   = -O -fasm

 

GhcLibWays += p

GhcProfiled= YES

 

SplitObjs  = NO

HADDOCK_DOCS   = NO

BUILD_DOCBOOK_HTML = NO

BUILD_DOCBOOK_PS   = NO

BUILD_DOCBOOK_PDF  = NO

 

endif

 

 

#  A Development build (stage 1)
-

 

ifeq $(BuildFlavour

Re: integer-simple

2011-07-31 Thread Malcolm Wallace 
I notice that ghci is loading integer-simple before loading base.  This at 
least explains why it cannot find a symbol from the base package - it hasn't 
been loaded yet.  So the question is why does integer-simple use any function 
from the base package at all? I'm fairly sure that the dependency graph is such 
that it should not.



On 30/07/2011, at 22:37, Chris Dornan ch...@chrisdornan.com wrote:

 Hi All,
 
  
 
 I thought I may as well try the same experiment 7.2.1-RC1 on completely 
 different hardware (a network v-server running CentOS 5 with ghc-6.12.3 
 installed) and indeed:
 
  
 
 ghci
 
 GHCi, version 7.2.0.20110728: http://www.haskell.org/ghc/  :? for help
 
 Loading package ghc-prim ... linking ... done.
 
 Loading package integer-simple ... linking ... ghc: 
 /usr/local/ghc/7.2.0.20110728/lib/ghc-7.2.0.20110728/integer-simple-0.1.0.0/HSinteger-simple-0.1.0.0.o:
  unknown symbol `base_ControlziExceptionziBase_patError_info'
 
 ghc: unable to load package `integer-simple'
 
  
 
 This has to be the way I am configuring the build – as y’all can see I am 
 configuring with a non-standard prefix, but otherwise it is a case of a clean 
 build from virginal sources with the appended build.mk.
 
  
 
 I think I am going to have to start looking at the failure mechanism…
 
  
 
 Chris
 
  
 
 snipety-snip
 
  
 
 # 
 -
 
 # A Sample build.mk
 
 #
 
 # Uncomment one of the following BuildFlavour settings to get the desired
 
 # overall build type, and then tweak the options in the relevant section
 
 # below.
 
  
 
 # Uncomment one of these to select a build profile below:
 
  
 
 # Full build with max optimisation (slow build)
 
 #BuildFlavour = perf
 
  
 
 # Fastest build (libs unoptimised):
 
 BuildFlavour = quickest
 
  
 
 # Fast build with optimised libraries:
 
 #BuildFlavour = quick
 
  
 
 # Profile the stage2 compiler:
 
 #BuildFlavour = prof
 
  
 
 # A development build, working on the stage 1 compiler:
 
 #BuildFlavour = devel1
 
  
 
 # A development build, working on the stage 2 compiler:
 
 #BuildFlavour = devel2
 
  
 
 GhcLibWays = v
 
  
 
 #  1. A Performance/Distribution build
 
  
 
 ifeq $(BuildFlavour) perf
 
  
 
 # perf matches the default settings, repeated here for comparison:
 
  
 
 SRC_HC_OPTS = -O -H64m
 
 GhcStage1HcOpts = -O -fasm
 
 GhcStage2HcOpts = -O2 -fasm
 
 GhcHcOpts   = -Rghc-timing
 
 GhcLibHcOpts= -O2 -XGenerics
 
 GhcLibWays += p
 
  
 
 ifeq $(PlatformSupportsSharedLibs) YES
 
 GhcLibWays += dyn
 
 endif
 
  
 
 endif
 
  
 
 #  A Fast build --
 
  
 
 ifeq $(BuildFlavour) quickest
 
  
 
 SRC_HC_OPTS= -H64m -O0 -fasm
 
 GhcStage1HcOpts= -O -fasm
 
 GhcStage2HcOpts= -O0 -fasm
 
 GhcLibHcOpts   = -O0 -fasm
 
 SplitObjs  = NO
 
 HADDOCK_DOCS   = NO
 
 BUILD_DOCBOOK_HTML = NO
 
 BUILD_DOCBOOK_PS   = NO
 
 BUILD_DOCBOOK_PDF  = NO
 
  
 
 endif
 
  
 
 #  A Fast build with optimised libs --
 
  
 
 ifeq $(BuildFlavour) quick
 
  
 
 SRC_HC_OPTS= -H64m -O0 -fasm
 
 GhcStage1HcOpts= -O -fasm
 
 GhcStage2HcOpts= -O0 -fasm
 
 GhcLibHcOpts   = -O -fasm
 
 SplitObjs  = NO
 
 HADDOCK_DOCS   = NO
 
 BUILD_DOCBOOK_HTML = NO
 
 BUILD_DOCBOOK_PS   = NO
 
 BUILD_DOCBOOK_PDF  = NO
 
  
 
 endif
 
  
 
 #  Profile the stage2 compiler ---
 
  
 
 ifeq $(BuildFlavour) prof
 
  
 
 SRC_HC_OPTS= -H64m -O0 -fasm
 
 GhcStage1HcOpts= -O -fasm
 
 GhcStage2HcOpts= -O -fasm
 
 GhcLibHcOpts   = -O -fasm
 
  
 
 GhcLibWays += p
 
 GhcProfiled= YES
 
  
 
 SplitObjs  = NO
 
 HADDOCK_DOCS   = NO
 
 BUILD_DOCBOOK_HTML = NO
 
 BUILD_DOCBOOK_PS   = NO
 
 BUILD_DOCBOOK_PDF  = NO
 
  
 
 endif
 
  
 
  
 
 #  A Development build (stage 1) -
 
  
 
 ifeq $(BuildFlavour) devel1
 
  
 
 SRC_HC_OPTS= -H64m -O -fasm
 
 GhcLibHcOpts   = -O -dcore-lint
 
 GhcStage1HcOpts= -Rghc-timing -O0 -DDEBUG
 
 GhcStage2HcOpts= -Rghc-timing -O -fasm
 
 SplitObjs  = NO
 
 HADDOCK_DOCS   = NO
 
 BUILD_DOCBOOK_HTML = NO
 
 BUILD_DOCBOOK_PS   = NO
 
 BUILD_DOCBOOK_PDF  = NO
 
  
 
 endif
 
  
 
 #  A Development build (stage 2) -
 
  
 
 ifeq $(BuildFlavour) devel2
 
  
 
 SRC_HC_OPTS= -H64m -O -fasm
 
 GhcLibHcOpts   = -O -dcore-lint
 
 GhcStage1HcOpts= -Rghc-timing -O -fasm
 
 GhcStage2HcOpts= -Rghc-timing -O0 -DDEBUG
 
 SplitObjs  = NO
 
 HADDOCK_DOCS   = NO
 
 BUILD_DOCBOOK_HTML = NO
 
 BUILD_DOCBOOK_PS   = NO
 
 BUILD_DOCBOOK_PDF  = NO
 
  
 
 endif

RE: integer-simple

2011-07-30 Thread Chris Dornan 
Hi All,

 

I thought I may as well try the same experiment 7.2.1-RC1 on completely
different hardware (a network v-server running CentOS 5 with ghc-6.12.3
installed) and indeed:

 

ghci

GHCi, version 7.2.0.20110728: http://www.haskell.org/ghc/  :? for help

Loading package ghc-prim ... linking ... done.

Loading package integer-simple ... linking ... ghc:
/usr/local/ghc/7.2.0.20110728/lib/ghc-7.2.0.20110728/integer-simple-0.1.0.0/
HSinteger-simple-0.1.0.0.o: unknown symbol
`base_ControlziExceptionziBase_patError_info'

ghc: unable to load package `integer-simple'

 

This has to be the way I am configuring the build - as y'all can see I am
configuring with a non-standard prefix, but otherwise it is a case of a
clean build from virginal sources with the appended build.mk.

 

I think I am going to have to start looking at the failure mechanism.

 

Chris

 

snipety-snip

 

#

-

# A Sample build.mk

#

# Uncomment one of the following BuildFlavour settings to get the desired

# overall build type, and then tweak the options in the relevant section

# below.

 

# Uncomment one of these to select a build profile below:

 

# Full build with max optimisation (slow build)

#BuildFlavour = perf

 

# Fastest build (libs unoptimised):

BuildFlavour = quickest

 

# Fast build with optimised libraries:

#BuildFlavour = quick

 

# Profile the stage2 compiler:

#BuildFlavour = prof

 

# A development build, working on the stage 1 compiler:

#BuildFlavour = devel1

 

# A development build, working on the stage 2 compiler:

#BuildFlavour = devel2

 

GhcLibWays = v

 

#  1. A Performance/Distribution
build

 

ifeq $(BuildFlavour) perf

 

# perf matches the default settings, repeated here for comparison:

 

SRC_HC_OPTS = -O -H64m

GhcStage1HcOpts = -O -fasm

GhcStage2HcOpts = -O2 -fasm

GhcHcOpts   = -Rghc-timing

GhcLibHcOpts= -O2 -XGenerics

GhcLibWays += p

 

ifeq $(PlatformSupportsSharedLibs) YES

GhcLibWays += dyn

endif

 

endif

 

#  A Fast build
--

 

ifeq $(BuildFlavour) quickest

 

SRC_HC_OPTS= -H64m -O0 -fasm

GhcStage1HcOpts= -O -fasm

GhcStage2HcOpts= -O0 -fasm

GhcLibHcOpts   = -O0 -fasm

SplitObjs  = NO

HADDOCK_DOCS   = NO

BUILD_DOCBOOK_HTML = NO

BUILD_DOCBOOK_PS   = NO

BUILD_DOCBOOK_PDF  = NO

 

endif

 

#  A Fast build with optimised libs
--

 

ifeq $(BuildFlavour) quick

 

SRC_HC_OPTS= -H64m -O0 -fasm

GhcStage1HcOpts= -O -fasm

GhcStage2HcOpts= -O0 -fasm

GhcLibHcOpts   = -O -fasm

SplitObjs  = NO

HADDOCK_DOCS   = NO

BUILD_DOCBOOK_HTML = NO

BUILD_DOCBOOK_PS   = NO

BUILD_DOCBOOK_PDF  = NO

 

endif

 

#  Profile the stage2 compiler
---

 

ifeq $(BuildFlavour) prof

 

SRC_HC_OPTS= -H64m -O0 -fasm

GhcStage1HcOpts= -O -fasm

GhcStage2HcOpts= -O -fasm

GhcLibHcOpts   = -O -fasm

 

GhcLibWays += p

GhcProfiled= YES

 

SplitObjs  = NO

HADDOCK_DOCS   = NO

BUILD_DOCBOOK_HTML = NO

BUILD_DOCBOOK_PS   = NO

BUILD_DOCBOOK_PDF  = NO

 

endif

 

 

#  A Development build (stage 1)
-

 

ifeq $(BuildFlavour) devel1

 

SRC_HC_OPTS= -H64m -O -fasm

GhcLibHcOpts   = -O -dcore-lint

GhcStage1HcOpts= -Rghc-timing -O0 -DDEBUG

GhcStage2HcOpts= -Rghc-timing -O -fasm

SplitObjs  = NO

HADDOCK_DOCS   = NO

BUILD_DOCBOOK_HTML = NO

BUILD_DOCBOOK_PS   = NO

BUILD_DOCBOOK_PDF  = NO

 

endif

 

#  A Development build (stage 2)
-

 

ifeq $(BuildFlavour) devel2

 

SRC_HC_OPTS= -H64m -O -fasm

GhcLibHcOpts   = -O -dcore-lint

GhcStage1HcOpts= -Rghc-timing -O -fasm

GhcStage2HcOpts= -Rghc-timing -O0 -DDEBUG

SplitObjs  = NO

HADDOCK_DOCS   = NO

BUILD_DOCBOOK_HTML = NO

BUILD_DOCBOOK_PS   = NO

BUILD_DOCBOOK_PDF  = NO

 

endif

 

#

-

# Other settings that might be useful

 

# profiled RTS

#GhcRtsCcOpts =  -pg -g

 

# Optimised/profiled RTS

#GhcRtsCcOpts = -O2 -pg

 

#GhcRtsWithFrontPanel = YES

#SRC_HC_OPTS += `gtk-config --libs`

 

# NoFib settings

NoFibWays =

STRIP=:

 

INTEGER_LIBRARY = integer-simple

end-snipety-snip

 

 

From: Chris Dornan [mailto:ch...@chrisdornan.com] 
Sent: 30 July 2011 21:35
To: 'glasgow-haskell-users@haskell.org'
Subject: RE: integer-simple

 

I tried building an integer-simple 7.2.1-RC1 with 7.0.3 binary-install on
Ubuntu 11.04.  ghci is still not happy:

 

chris@Ubuntu-11:~/etc$ ghci

GHCi, version 7.2.0.20110728

integer-simple

2011-07-29 Thread Chris Dornan 
Hi All,

 

I am still having difficulty getting a plain GHC build with INTEGER_LIBRARY
= integer-simple. (I outlined my problem here yesterday
http://www.haskell.org/pipermail/glasgow-haskell-users/2011-July/020631.htm
l .)

 

I suspected my failure to get a vanilla build (with GMP) was a minor issue
with RHEL 5 and indeed a vanilla build of the the compiler  goes through no
problem on RHEL 6, producing a working 6.12.3 GHC installation.

 

But when I repeat with  INTEGER_LIBRARY = integer-simple (on quick test) I
get (the now familiar):

 

GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help

Loading package ghc-prim ... linking ... done.

ghc:
/usr/local/ghc/6.12.3-si/lib/ghc-6.12.3/integer-simple-0.1.0.0/HSinteger-sim
ple-0.1.0.0.o: unknown symbol `base_ControlziExceptionziBase_patError_info'

Loading package integer-simple ... linking ... ghc: unable to load package
`integer-simple'

 

RHEL 5 and 6 are very different development environments yet all my attempts
to build with a variety of source trees from 6.12.1 to 7.0.4 with
INTEGER_LIBRARY = integer-simple has ended here. There is clearly something
I am doing wrong! (Though it is difficult to see what.)

 

Does anybody have any idea what could be causing this?

 

Is anybody else doing integer-simple builds? 

 

It would be nice to get some info on the configurations that are working.

 

Thanks in advance!

 

Chris

 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple

2011-07-29 Thread Ian Lynagh 
On Fri, Jul 29, 2011 at 05:51:23PM +0100, Chris Dornan wrote:
 
 But when I repeat with  INTEGER_LIBRARY = integer-simple (on quick test)
 
 GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help

Note that 6.12.3 is quite old now, and neither that branch or the 7.0
branch are still being developed.

By quick test do you mean the quickest build flavour from
mk/build.mk.sample?

I've just validated HEAD with INTEGER_LIBRARY=integer-simple and the
build went through fine, and ghci works.


Thanks
Ian


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple

2011-07-29 Thread Daniel Fischer 
On Friday 29 July 2011, 18:51:23, Chris Dornan wrote:
 Hi All,
 
 
 
 I am still having difficulty getting a plain GHC build with
 INTEGER_LIBRARY = integer-simple. (I outlined my problem here yesterday
 http://www.haskell.org/pipermail/glasgow-haskell-users/2011-July/020631
 .htm l .)

 RHEL 5 and 6 are very different development environments yet all my
 attempts to build with a variety of source trees from 6.12.1 to 7.0.4
 with INTEGER_LIBRARY = integer-simple has ended here. There is clearly
 something I am doing wrong! (Though it is difficult to see what.)
 
 Does anybody have any idea what could be causing this?
 

Not I, sorry.

 
 
 Is anybody else doing integer-simple builds?
 
 It would be nice to get some info on the configurations that are
 working.

After your post yesterday, I built HEAD with integer-simple (build flavour 
perf, though, not quickest; openSuSE-11.4, x86_64; built with 7.0.4) and it 
worked [ghci and a few test programmes].

Maybe you should try building with GHC-7 (and different build flavours?).

Cheers,
Daniel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: integer-simple

2011-07-29 Thread Chris Dornan 
Thanks Daniel.

I have just now built the 7.2.1 RC1 with integer-simple on CentOS 6 with the 
same failure.

It doesn't surprise me -- there is clearly something in my setup that is 
causing this problem.

But it's good to get it confirmed  -- thanks!

Chris

-Original Message-
From: Daniel Fischer [mailto:daniel.is.fisc...@googlemail.com] 
Sent: 29 July 2011 22:02
To: glasgow-haskell-users@haskell.org
Cc: Chris Dornan
Subject: Re: integer-simple

On Friday 29 July 2011, 18:51:23, Chris Dornan wrote:
 Hi All,
 
 
 
 I am still having difficulty getting a plain GHC build with 
 INTEGER_LIBRARY = integer-simple. (I outlined my problem here 
 yesterday
 http://www.haskell.org/pipermail/glasgow-haskell-users/2011-July/0206
 31
 .htm l .)

 RHEL 5 and 6 are very different development environments yet all my 
 attempts to build with a variety of source trees from 6.12.1 to 7.0.4 
 with INTEGER_LIBRARY = integer-simple has ended here. There is clearly 
 something I am doing wrong! (Though it is difficult to see what.)
 
 Does anybody have any idea what could be causing this?
 

Not I, sorry.

 
 
 Is anybody else doing integer-simple builds?
 
 It would be nice to get some info on the configurations that are 
 working.

After your post yesterday, I built HEAD with integer-simple (build flavour 
perf, though, not quickest; openSuSE-11.4, x86_64; built with 7.0.4) and it 
worked [ghci and a few test programmes].

Maybe you should try building with GHC-7 (and different build flavours?).

Cheers,
Daniel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: integer-simple

2011-07-29 Thread Chris Dornan 
Thanks Ian,

It's much appreciated. As I said to Daniel, I have just tried building 7.2.1
RC1 with the same failure. 

Yes, by quick-test I mean the build flavour. (Basically I am explaining
exactly how I am configuring the default build, which does work for me.)

My point was that I had worked my way through pretty every post-6.12.1
official release, switching between CentOS 5  CentOS 6, building with a
variety of binary releases, with the same result -- and it's still happening
with 7.2.1 RC1!

Clearly I am doing something very, very silly -- but what?

I can see two obvious ways forward:

* try installing another of the Linux distros and seeing if I can
repeat the problem there or

* spend some time digging into one of the broken builds to try and
find out what is happening.

I think the second option may be more productive.
 
If anybody has any bright ideas I will be happy to try them out.

Cheers,

Chris



-Original Message-
From: Ian Lynagh [mailto:ig...@earth.li] 
Sent: 29 July 2011 21:42
To: Chris Dornan
Cc: glasgow-haskell-users@haskell.org
Subject: Re: integer-simple

On Fri, Jul 29, 2011 at 05:51:23PM +0100, Chris Dornan wrote:
 
 But when I repeat with  INTEGER_LIBRARY = integer-simple (on quick 
 test)
 
 GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help

Note that 6.12.3 is quite old now, and neither that branch or the 7.0 branch
are still being developed.

By quick test do you mean the quickest build flavour from
mk/build.mk.sample?

I've just validated HEAD with INTEGER_LIBRARY=integer-simple and the build
went through fine, and ghci works.


Thanks
Ian


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

integer-simple

2011-07-28 Thread Chris Dornan 
Hi All,

 

I have been trying to get a simple-integer build for GHC without success. It
always ends with the build going through fine, but when I try to run ghci I
get:

 

GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help

Loading package ghc-prim ... linking ... done.

ghc:
/usr/local/ghc/6.12.3-is/lib/ghc-6.12.3/integer-simple-0.1.0.0/HSinteger-sim
ple-0.1.0.0.o: unknown symbol `base_ControlziExceptionziBase_patError_info'

Loading package integer-simple ... linking ... ghc: unable to load package
`integer-simple'

 

My MO is to

 

. get binary GHC package, install it and put it on the path;

. unpack the source distribution and set up build.mk, usually with
quicktest, always with INTEGER_LIBRARY = integer-simple;

. configure, build and install;

. switch the path over from the binary to the new build and run
ghci.

 

I have tried this many combinations of build and source trees from
ghc-6.12.1 up to 7.0.4 on CentOS/RHEL 5  6 with the same result.

 

The above output was taken from a 6.12.3 source tree built with 6.12.2
binaries.

 

Further:

 

. I use 6.12.3 binaries heavily on CentOS 5 with no issue.

. On the couple of occasions I have tried a vanilla build (no
build.mk), the build breaks down with GMP link errors. Configuring with
--with-gmp-includes=/usr/local/include  and --with-gmp-libs=/usr/local/lib
didn't help. (I did not persist for obvious reasons.)

. At least Mik Konecny appears to got this to work for 6.12.3
http://code.google.com/p/hmpfr/wiki/GHCWithoutGMP .

 

'Tis all very odd! Anybody any idea what I am doing wrong?

 

Chris

 

 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-23 Thread naur 
Hello,

Yet another data point would be my current use of Haskell in various integer 
factorization activities where I would consider the performance, even for 
relatively large integers (say, 100-1000 decimal digits) very important. 
However, I wouldn't complain if some simple and manageable implementation were 
introduced, as long as the re-introduction of the efficient use of some 
well-tuned library (like GMP) were not hampered needlessly.

Best regards
Thorkil

- Original meddelelse -
 Fra: Yitzchak Gale g...@sefer.org
 Til: Greg Fitzgerald gari...@gmail.com
 Cc: glasgow-haskell-users@haskell.org
 Dato: Tir, 23. feb 2010 00:04
 Emne: Re: integer-simple by default
 
 I wrote:
  As another data point, Python has also re-invented the GMP
  wheel, likely for the same licensing reasons. They have
  been using a simple implementation of Karatsuba
  multiplication for years. I have never heard of anyone
  complaining about it
 
 Greg Fitzgerald wrote:
  Looks like they swapped out their integer implementation for
 Python3
 
 Interesting! This will be new in Python 3.2 - the first changes in
 many
 years. It's not exactly swapped out, but there are many changes.
 At first glance, it looks like better 64-bit support, a new
 division
 algorithm via floating-point, a new exponentiation algorithm
 using a 5-bits-at-a-time trick in some cases, optimized Read
 and Show instances (pardon the expression), a few other things.
 A lot of the new stuff seems to be from HAC. As before, everything
 is fully explained in expository comments inside the code, with
 references; a worthwhile read. Multiplication is still the same
 basic
 idea though - naive up to about 2000 bits, followed by just
 Karatsuba and nothing more.
 
 Thanks,
 Yitz
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-22 Thread Yitzchak Gale 
Isaac Dupree:
 We could try to find out how large Integers get, in practice, in
 existing Haskell code (this may be difficult to find out).

Daniel Fischer wrote:
 Just as a data-point, my code rarely exceeds 128 bits (at least, beyond
 that performance isn't so important anymore).

And Daniel, who is part of the Project Euler team, uses large
integers far more than most people.

As another data point, Python has also re-invented the GMP
wheel, likely for the same licensing reasons. They have
been using a simple implementation of Karatsuba
multiplication for years. I have never heard of anyone
complaining about it. Furthermore, they currently use naive
multiplication and don't even bother with Karatsuba for
less than about 2000 bits on most recent platforms.

Regards,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-22 Thread Greg Fitzgerald 
 As another data point, Python has also re-invented the GMP
 wheel, likely for the same licensing reasons. They have
 been using a simple implementation of Karatsuba
 multiplication for years. I have never heard of anyone
 complaining about it

Thanks for the data point.

Looks like they swapped out their integer implementation for Python3:
http://gmplib.org/list-archives/gmp-discuss/2008-November/003434.html

Here's the code from January 30, 2010:
http://svn.python.org/view/python/trunk/Objects/longobject.c?view=markup

More data points:
http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic

-Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-22 Thread Isaac Dupree 
I think it would be great to have a benchmark, to test Integer 
performance at various implementations.  Perhaps it could test speed of 
Int, Int64, Int32 as well (for computations that fit within them).  I 
suppose tight numeric loops are key to measuring performance in a useful 
way (except for incredibly larger Integers).  Are there existing 
benchmarks?  (If not, is there a good benchmarking library that I ought 
to use if I try to write a benchmark?)


On 02/22/10 15:15, Greg Fitzgerald wrote:

...
More data points:
...


Thanks!
Code re-use is nice (if we can use one of those BSD-licensed versions) ; 
although it may turn out useful to write our Integer implementation in 
Haskell if it helps the optimizer out with small-valued Integers.


-Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-22 Thread Yitzchak Gale 
I wrote:
 As another data point, Python has also re-invented the GMP
 wheel, likely for the same licensing reasons. They have
 been using a simple implementation of Karatsuba
 multiplication for years. I have never heard of anyone
 complaining about it

Greg Fitzgerald wrote:
 Looks like they swapped out their integer implementation for Python3

Interesting! This will be new in Python 3.2 - the first changes in many
years. It's not exactly swapped out, but there are many changes.
At first glance, it looks like better 64-bit support, a new division
algorithm via floating-point, a new exponentiation algorithm
using a 5-bits-at-a-time trick in some cases, optimized Read
and Show instances (pardon the expression), a few other things.
A lot of the new stuff seems to be from HAC. As before, everything
is fully explained in expository comments inside the code, with
references; a worthwhile read. Multiplication is still the same basic
idea though - naive up to about 2000 bits, followed by just
Karatsuba and nothing more.

Thanks,
Yitz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-21 Thread Isaac Dupree 

On 02/21/10 13:14, Ian Lynagh wrote:

On Sat, Feb 20, 2010 at 02:56:53PM -0500, Isaac Dupree wrote:

-what am I trying to accomplish (at least, performance-wise)?


I think opinions are divided on this.

Performance with word-sized Integer's is definitely important.


This is true.

We could start a discussion on the Libraries list -- although I'm sure 
it would also not reach a clear conclusion.


We could try to find out how large Integers get, in practice, in 
existing Haskell code (this may be difficult to find out).


We could make sure there's a good non-builtin-to-ghc GMP-binding library 
(Is there one? Is it even possible yet, in a way that doesn't conflict 
with GHC's builtin GMP?).  Then people would have a place to turn if 
they need GMP's performance for something particular.



-what might be a good low-level format? (And is it important to strew
unboxed ints all over the place, or is it fine to skip this and count on
the optimizer?)


I think relying on the optimiser is OK, but don't forget that you don't
have the standard (+) etc.


oh okay, interesting.  I think I'd best start by finding out where 
integer-simple lies in the dependency tree.


-Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-21 Thread Daniel Fischer 
Am Sonntag 21 Februar 2010 19:56:54 schrieb Isaac Dupree:
 We could try to find out how large Integers get, in practice, in
 existing Haskell code (this may be difficult to find out).

Just as a data-point, my code rarely exceeds 128 bits (at least, beyond 
that performance isn't so important anymore).
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-21 Thread Isaac Dupree 

On 02/21/10 14:18, Daniel Fischer wrote:

Am Sonntag 21 Februar 2010 19:56:54 schrieb Isaac Dupree:

We could try to find out how large Integers get, in practice, in
existing Haskell code (this may be difficult to find out).


I suspect (just guessing...) that a more reliable way to find out is to 
instrument integer-simple to report the sizes of integers it handles. 
For example, if you use Rational, (even toRational/fromRational), you 
might be handling Integers somewhat larger than you thought you were. 
And this could also report on how often the integers get that large.


(Also it's probably only tough operations like multiplication and 
division that we need to worry about for large numbers.  It's easy to 
get linear-time addition, etc.


Incidentally, for operations like Large Number plus or minus Small 
Number, it's possible to use a representation that has laziness and 
sharing to achieve amortized O(min(m,n)) time.  Which is a nice 
property... which I believe I implemented in HIntegerByInt... but there 
are probably disadvantages to doing it this way too.)


-Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-20 Thread Greg Fitzgerald 
 You can dynamically link libgmp on windows. That might be easier:

Do you know if the dynamic link escape hatch has ever held up in
court?  Last time I looked into it, the free software community had
mixed opinions.  In any case, giving GMP the boot alleviates any
licensing concerns, makes the GHC build a little simpler, and allows
users to create standalone executables.  Is there any reason we
shouldn't attempt to make integer-simple the default?

-Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-20 Thread Ian Lynagh 
On Sat, Feb 20, 2010 at 11:11:15AM -0800, Greg Fitzgerald wrote:
 
 In any case, giving GMP the boot alleviates any
 licensing concerns, makes the GHC build a little simpler, and allows
 users to create standalone executables.  Is there any reason we
 shouldn't attempt to make integer-simple the default?

I think defaulting to a Haskell Integer would be good if we can achieve
it (i.e. if we can get a library that performs well enough, whatever
that means).

The algorithms in integer-simple may be too simple, although I don't
think I've done any timings since
http://hackage.haskell.org/trac/ghc/ticket/601#comment:14

There's also HIntegerByInt:
http://www.haskell.org/pipermail/libraries/2007-August/007909.html
although it would need to be changed to user lower level types etc.


Thanks
Ian

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-20 Thread Isaac Dupree 

On 02/20/10 14:11, Greg Fitzgerald wrote:

You can dynamically link libgmp on windows. That might be easier:


Do you know if the dynamic link escape hatch has ever held up in
court?  Last time I looked into it, the free software community had
mixed opinions.


GMP is under LGPL, which is designed for this very purpose: to allow 
proprietary code to link to it as long as it is easy to replace the Free 
code with a different version of Free code (for example, by replacing a 
dynamic library).  Is there any reason to doubt the FSF's efforts? (Note 
that LGPL doesn't work as well for Haskell code as for C code because 
Haskell compilers tend to do a lot more inlining; but GMP is C code.)



In any case, giving GMP the boot alleviates any
licensing concerns, makes the GHC build a little simpler, and allows
users to create standalone executables.


However the 3-clause BSD license is obviously at least somewhat simpler 
for lawyers.



Is there any reason we
shouldn't attempt to make integer-simple the default?


If you know that none of your code or libraries are using any 
particularly large integers [how would you know, though?], then it 
should perform alright.  GMP, however, is the result of years of work 
making operations on integers large and small be reasonably performant 
-- work that Haskell would be foolhardy to duplicate, I'm guessing. 
(Depending what our standards are... Is reasonable performance for 
multiplying integers less than 320 bits long, say, good enough? What 
happens when someone wants state-of-the-art performance?  Is a 
nonstandard-Integer-type GMP-binding sufficient for these uses?)


-Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-20 Thread Isaac Dupree 

On 02/20/10 14:37, Ian Lynagh wrote:

There's also HIntegerByInt:
 http://www.haskell.org/pipermail/libraries/2007-August/007909.html
although it would need to be changed to user lower level types etc.


that's true, (I wrote it), the current form uses a list-based 
implementation with a lot of recursion and I'd have to see how well that 
converts to some sort of array [at least I assume arrays are the only 
reasonable storage layout...].  I used a couple algorithms to make 
operations faster (at least multiplication -- I don't remember the 
details) so it might be useful code to pick up again.  I have a bit of 
time now, if anyone's seriously interested, I could work on haskell 
integer code.  As long as I had certain standards


-what am I trying to accomplish (at least, performance-wise)?
-what might be a good low-level format? (And is it important to strew 
unboxed ints all over the place, or is it fine to skip this and count on 
the optimizer?)


-Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: integer-simple by default

2010-02-19 Thread Don Stewart 
garious:
 Static linking to GMP on Windows is sending me towards a bunch of red
 tape at work.  What can I do to make integer-simple the default
 integer library for GHC?  Need anything more than test suite and
 performance metrics?  Any date planned for the 6.12.2 release?

You can dynamically link libgmp on windows. That might be easier:

http://haskell.forkio.com/gmpwindows
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users