Re: new ghc under solaris
Simon Marlow wrote: What version of gcc are you using? I used gcc_2.95.3 until I discovered the warning: LdvProfile.c:43: #error Please use gcc 3.0+ to compile this file with DEBUG; gcc 3.0 miscompiles it I've switched to gcc_3.4.3. Now the final linking of the stage2 compiler fails (with thousands of undefined symbols). ../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.5 -H16m -O [...] DriverState_WayThreaded_closure stage2/main/DriverFlags.o ld: fatal: Symbol referencing errors. No output written to stage2/ghc-6.5 collect2: ld returned 1 exit status As a linker (that ./configure finds) I use gnu-ld_2.14, but gcc_3.4.3 uses the solaris linker (see below). Cheers Christian [EMAIL PROTECTED] - gcc -v Reading specs from /export/software/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/usr/local/lang -program-suffix=_3.4.3 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 --enable-shared=libstdc++ --disable-nls Thread model: posix gcc version 3.4.3 [EMAIL PROTECTED] - ld --version GNU ld version 2.14 20030612 Copyright 2002 Free Software Foundation, Inc. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: RFC: hyperlinks in Haddock docs
On 24 February 2005 20:11, Sven Panne wrote: Simon Marlow wrote: On 22 February 2005 19:37, Duncan Coutts wrote: Excellent! Thanks a lot. Any hint as to when the next Haddock release will be? Maybe when I've got this GHC release out of the way and my hair has grown back :-S Before we do a release, I think two issues should be solved IMHO: * The table/CSS chaos on the contents page has to be cleaned up, the package ids on the right look like being layout by somebody drunk... %-) They don't look too bad to me... a bit far to the right, perhaps, but not too bad. Perhaps some lines in that table would help, or alternating grey/white background for the rows? * The state of the +/- buttons should be remembered when using backward/forward in a browser (cookies + ECMA script?). If anyone knows how to do this, then please go ahead. I don't think it's urgent for the release though - by default the collapsible sections are now expanded, and anyway the right way to use the contents page is to middle-click on the module name in Firefox ;-) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: new ghc under solaris
On 25 February 2005 10:09, Christian Maeder wrote: Simon Marlow wrote: What version of gcc are you using? I used gcc_2.95.3 until I discovered the warning: LdvProfile.c:43: #error Please use gcc 3.0+ to compile this file with DEBUG; gcc 3.0 miscompiles it I've switched to gcc_3.4.3. Now the final linking of the stage2 compiler fails (with thousands of undefined symbols). ../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.5 -H16m -O [...] DriverState_WayThreaded_closure stage2/main/DriverFlags.o ld: fatal: Symbol referencing errors. No output written to stage2/ghc-6.5 collect2: ld returned 1 exit status As a linker (that ./configure finds) I use gnu-ld_2.14, but gcc_3.4.3 uses the solaris linker (see below). This looks like a mangler or a splitter problem (those manky Perl scripts we use to postprocess assembly code). Probably gcc 3.4.3 is generating something we don't recognise. Could you try the following: - Add SplitObjs=NO to build.mk, recompile the libraries (make clean make) and try to compile a simple program with the stage1 ghc. If that works, then it's a splitter problem. - If you get link errors, then $ cd libraries/base $ rm -f GHC/Base.o $ make GHC/Base.o EXTRA_HC_OPTS='-keep-s-file -keep-raw-s-file' and send me the contents of GHC/Base.s and GHC/Base.raw_s. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Infix typeconstructors shown as prefix
Ive fixed this to print the parens round the type constructor anyway.
But it won't print infix. Doing the right thing requires knowledge of
fixities, which isn't (yet) plumbed to the right place
S
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Remi Turk
| Sent: 20 February 2005 22:00
| To: glasgow-haskell-users@haskell.org
| Subject: Infix typeconstructors shown as prefix
|
| Hi,
|
| with the following definitions
|
| {-# OPTIONS -fglasgow-exts #-}
| data a :++: b
| class a :--: b
|
| ghci prints the infix type(classe)s as prefix:
|
| *Main :i :++:
| data :++: a b -- Defined at foo.hs:2:7
|
| *Main :i :--:
| class :--: a b where -- Defined at foo.hs:3:8
|
| or (a real-world example):
|
| *Main :t fac (One:@Zero:@Zero)
| fac (One:@Zero:@Zero) :: :@ (:@ (:@ (:@ One One) Zero) Zero) Zero
|
| Is this a bug, a feature or just Not Implemented Yet(TM)?
|
| Groeten,
| Remi
|
| P.S. Are infix class-names a documented extension at all?
|
| --
| Nobody can be exactly like me. Even I have trouble doing it.
| ___
| 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: Kinds in ghc
Well, it's a bug really, but not one that's easy to fix. Thanks for pointing it out; I've added it as a SourceForge bug so we don't forget it. SImon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Johan Glimming | Sent: 24 February 2005 12:31 | To: glasgow-haskell-users@haskell.org | Subject: Kinds in ghc | | Hi | | I can report success on compiling latest CVS on Mac OS X including | stage 2 with ghci support. (greencard does not compile, but that's not | a problem for ghc to be compiled it seems.) | | Now that I have the compiler up, I notice that types are not reported | as before. Instead of nice t,t', etc, I get random strings: | | Kind error: Expecting kind `k_a1JA - k_a1JE - k_a1JI - *', | but `DUnit t' has kind `k_a1JA - k_a1JE - *' | | Is this a mere debug mode I have enabled by accident (no parameter | passed to make or configure though), or is this something else? | | P.S. infix type synonyms seems to work well so far! | | Johan Glimming. | | ___ | 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: Help with a Shootout program
Welcome to the club :-)
http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg06012.html
I tried Simon's version, but it throws a Fail: Ix{Int}.index: Index
(5) out of range ((0,4)) error. Haven't tracked down the cause yet.
So I guess that the upshot is just that GHC is slow on this test.
Is lazy evaluation what is slowing this down so badly?
- Alson
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Help with a Shootout program
From: Simon Marlow [mailto:[EMAIL PROTECTED]
PackedStrings are still slow in 6.x. I know there are various other
PackedString implementations out there, we just need to
incorporate one.
They certainly seem to be. Below are the profiles (compiled with -O2; ran
them twice; took the second run) of Simon's old PackedString version, and
Alson's Hash version. Simon's uses way more memory, too. I might try some
more profiling later to narrow down the slow bits.
From: Alson Kemp [mailto:[EMAIL PROTECTED]
I tried Simon's version, but it throws a Fail:
Ix{Int}.index: Index
(5) out of range ((0,4)) error. Haven't tracked down the cause yet.
Here's the fix (subtract one from (lengthPS ps)):
-- Looks bad, but GHC does a great job of optimising it:
hashPS :: PackedString - Int
hashPS ps = foldr f 0 (map (ord.indexPS ps) [0..((lengthPS ps) - 1)])
where f n m = n + m * 128 `mod` 1048583
--- Alson's:
spellcheck +RTS -p -hr -H10m -K20m -RTS
total time =1.84 secs (92 ticks @ 20 ms)
total alloc = 69,112,588 bytes (excludes profiling overheads)
COST CENTREMODULE %time %alloc
main Main 58.7 21.2
spellcheck Main 23.9 34.2
buildHash Main 17.4 44.6
individualinherited
COST CENTREMODULE no.entries %time %alloc %time
%alloc
MAIN MAIN 1 0 0.00.0 100.0
100.0
main Main146 1 58.7 21.2 100.0
100.0
spellcheck Main149 0 23.9 34.223.9
34.2
buildHashMain148 1 17.4 44.617.4
44.6
CAF Main140 1 0.00.0 0.0
0.0
main Main147 0 0.00.0 0.0
0.0
CAF GHC.Handle 103 6 0.00.0 0.0
0.0
CAF System.Posix.Internals 81 4 0.00.0 0.0
0.0
--- Simon's:
spellcheck +RTS -p -hr -H10m -K20m -RTS
total time =6.90 secs (345 ticks @ 20 ms)
total alloc = 351,514,332 bytes (excludes profiling overheads)
COST CENTREMODULE %time %alloc
main Main 93.0 93.6
hashPS Main 3.22.4
elemHashTable Main 2.00.1
addToHashTable Main 1.70.2
CAFData.PackedString 0.03.6
individualinherited
COST CENTRE MODULEno.entries %time %alloc %time
%alloc
MAIN MAIN1 0 0.00.0 100.0
100.0
mainMain 166 1 93.0 93.6 100.0
96.4
elemHashTable Main 171 38618 2.00.1 2.9
1.3
hashPSMain 172 38618 0.91.2 0.9
1.2
addToHashTable Main 168 38617 1.70.2 4.1
1.4
hashPSMain 169 38617 2.31.2 2.3
1.2
CAF Main 160 4 0.00.0 0.0
0.0
hashPS Main 170 0 0.00.0 0.0
0.0
main Main 167 0 0.00.0 0.0
0.0
CAF GHC.Handle123 5 0.00.0 0.0
0.0
CAF System.Posix.Internals 101 4 0.00.0 0.0
0.0
CAF Data.PackedString 86 1 0.03.6 0.0
3.6
-
*
Confidentiality Note: The information contained in this message, and any
attachments, may contain confidential and/or privileged material. It is
intended solely for the person(s) or entity to which it is addressed. Any
review, retransmission, dissemination, or taking of any action in
reliance upon this information by persons or entities other than the
intended recipient(s) is prohibited. If you received this in error, please
contact the sender and delete the material from any computer.
*
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: gunfoldl
There's a real bug in the desugarer here, quite apart from the
programming question. I'll look into it
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Akos Korosmezey
| Sent: 18 February 2005 20:05
| To: GHC-users list
| Subject: gunfoldl
|
|
| I wrote a little data structure with quantified constructors:
|
| module MyModule where
|import Data.Generics
|import Data.HashTable
|
|data Item = forall a. (Data a) = Leaf Bool a
| | forall a. (Data a) = Branch Bool a Int Int
|
| deriving (Typeable)
|
| I want it to make an instance of Data:
|
|instance Data Item where
|gfoldl k z (Leaf b v) = z (Leaf b) `k` v
|gfoldl k z (Branch b v a1 a2) = z (\x - Branch b x a1 a2) `k`
v
|--gunfoldl k z c = case constrIndex c of
|--1 - k z (Leaf undefined
| undefined)
|toConstr (Leaf _ _) = leafConstr
|toConstr (Branch _ _ _ _) = branchConstr
|dataTypeOf _ = itemDataType
|
|itemDataType = mkDataType Subliminal.Item [leafConstr,
branchConstr]
|leafConstr = mkConstr itemDataType Leaf [] Prefix
|branchConstr = mkConstr itemDataType Branch [] Prefix
|
| But, when I try to compile it with ghc-6.4-20050217:
|
| ghc -fglasgow-exts -i. -c kicsi.hs
|
| kicsi.hs:13:4:
|Warning: No explicit method nor default method for `gunfold'
| In the instance declaration for `Data Item'
| ghc-6.4.20050217: panic! (the `impossible' happened, GHC version
| 6.4.20050217):
|cgPanic
|k{v a1vu}
|static binds for:
|local binds for:
|gunfold{v r22q}
|SRT labelghc-6.4.20050217: panic! (the `impossible' happened, GHC
| version 6.4.20050217):
|initC: srt
|
| Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
| or http://sourceforge.net/projects/ghc/.
|
| If I uncomment the gunfoldl lines:
|
| ghc -fglasgow-exts -i. -c kicsi.hs
|
| kicsi.hs:12:8: `gunfoldl' is not a (visible) method of class `Data'
|
| Compilation exited abnormally with code 1 at Fri Feb 18 20:55:32
|
| Could you please help me?
|
| Thanks
| Akos
| --
| ~~~
| ~~
| Akos Korosmezey Tel:+36-1-439-5936
| Ericsson Telecom Ltd. ETH/GSCD/RUNB Fax:+36-1-437-7576
| P.O.B. 107, H-1300 Budapest, HungaryHome: +36-26-342-687
| mailto:[EMAIL PROTECTED] Mobile: +36-30-740-7732
| ~~~
| ~~
|
| ___
| 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: Help with a Shootout program
On 25 February 2005 13:46, Alson Kemp wrote:
Welcome to the club :-)
http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg06012.h
tml
I tried Simon's version, but it throws a Fail: Ix{Int}.index:
Index
(5) out of range ((0,4)) error. Haven't tracked down the cause yet.
So I guess that the upshot is just that GHC is slow on this
test.
Is lazy evaluation what is slowing this down so badly?
There's no fundamental problem here. We just need decent support for
packed strings and hash tables (or tries?) of them.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc HEAD and tee
Hi, we used redirect output of ghc via tee (within a Makefile). With the new ghc this randomly fails now. Does anyone have an explanation for this? ghc omitted args 21 | tee log yields: Skipping Main ( hets.hs, hets.o ) Linking ... tee: write error The linked binary and the log file are ok afterwards (and the mere size of the log is also no problem). Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available (breakage on x86-64)
Simon Marlow wrote: Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend-I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs-c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Help with a Shootout program
Here's your program, but a little slimmer. I think size counts for something in the shootout. Still runs at the same speed though :-( The program seems to spend about 50% reading the files, 22% building the hash table (7% chopping input into lines, 11% inserting into table), 25% spellchecking (11% chopping input into lines, 12% hash lookup). So until String IO gets a bit faster, you're stuck. You could look into using Peter Simons' BlockIO, and operating over bytes rather than chars. But then you'd have to include that in the submitted code, because it's not part of the standard libraries. module Main where import Data.HashTable import System.IO buildHash input = do table - new (==) hashString sequence_ [ insert table w True | w - lines input ] return table check :: HashTable String Bool - String - IO () check table w = do r - Data.HashTable.lookup table w maybe (putStrLn w) (const $ return ()) r spellcheck table input = sequence_ [ check table w | w - lines input ] main = do table - (readFile Usr.Dict.Words = buildHash) hGetContents stdin = spellcheck table - * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHCi and C++.
Greetings fellow Haskellers and other readers, During my ongoing research on doing whatever I feel like, I discovered that using C++ libaries in GHCi (no problems with GHC) wasn't as pleasant as I had hoped. Apparently C++ sources requires to be linked with crtbegin.o and crtend.o (and others?) and I was wondering how to solve this nicely. Any hints or pointers would be greatly appreciated. -- Friendly, Lemmih ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and C++.
On Fri, 2005-02-25 at 19:05 +0100, Lemmih wrote: Greetings fellow Haskellers and other readers, During my ongoing research on doing whatever I feel like, I discovered that using C++ libaries in GHCi (no problems with GHC) wasn't as pleasant as I had hoped. Apparently C++ sources requires to be linked with crtbegin.o and crtend.o (and others?) and I was wondering how to solve this nicely. Any hints or pointers would be greatly appreciated. How about creating a dummy ghc package that has no Haskell code but specifies all the nasty link time options. i.e. using the extra_libraries, extra_ghc_opts, extra_cc_opts and extra_ld_opts fields. Then when compiling your program you just use -package c++ or (-package cpp or cpp-support if c++ is not a valid package name). if you make packages that depend on C++ support it's still easy, just make the new package depend on the cpp package. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and C++.
During my ongoing research on doing whatever I feel like, I discovered that using C++ libaries in GHCi (no problems with GHC) wasn't as pleasant as I had hoped. Apparently C++ sources requires to be linked with crtbegin.o and crtend.o (and others?) and I was wondering how to solve this nicely. Any hints or pointers would be greatly appreciated. I think the files crtbegin.o and crtend.o are Linux-specific or maybe GNU-binutils-specific. Different platforms tend to have different strange requirements for C++ code. Loading shared libraries that happen to be written in C++ into GHCi shouldn't be a problem (or is it? definitely works on Mac OS X). Loading C++ .o files is a different story. Generally speaking, there are at least two things that set C++ .o files apart from normal C .o files: *) static constructors/destructors Sometimes there are pieces of code that expect to be called before main() or at program termination. The GHCi Linker doesn't support this, so some code may crash because things haven't been initialised properly. *) multiple definitions There is often some code in C++ header files (e.g. templates, inline functions, class members declared in the class declaration). These pieces of code are sometimes inlined, but sometimes they are not; in that case, gcc generates code for them in every .o file that uses them and counts on the linker to just include one version in the final executable. The GHCi linker will probably just abort and complain about multiply-defined symbols. The above is just theory, there might be even more problems in practice :-( . Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and C++.
On Fri, 25 Feb 2005 18:27:03 +, Duncan Coutts [EMAIL PROTECTED] wrote: On Fri, 2005-02-25 at 19:05 +0100, Lemmih wrote: Greetings fellow Haskellers and other readers, During my ongoing research on doing whatever I feel like, I discovered that using C++ libaries in GHCi (no problems with GHC) wasn't as pleasant as I had hoped. Apparently C++ sources requires to be linked with crtbegin.o and crtend.o (and others?) and I was wondering how to solve this nicely. Any hints or pointers would be greatly appreciated. How about creating a dummy ghc package that has no Haskell code but specifies all the nasty link time options. i.e. using the extra_libraries, extra_ghc_opts, extra_cc_opts and extra_ld_opts fields. Then when compiling your program you just use -package c++ or (-package cpp or cpp-support if c++ is not a valid package name). if you make packages that depend on C++ support it's still easy, just make the new package depend on the cpp package. Thanks for replying and it all sounds nice, but I'm not sure which linker options I'm missing since the location of the crt*.o files appears to be implementation specific. -- Friendly, Lemmih ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and C++.
On Fri, 25 Feb 2005 13:58:52 -0500, Wolfgang Thaller [EMAIL PROTECTED] wrote: During my ongoing research on doing whatever I feel like, I discovered that using C++ libaries in GHCi (no problems with GHC) wasn't as pleasant as I had hoped. Apparently C++ sources requires to be linked with crtbegin.o and crtend.o (and others?) and I was wondering how to solve this nicely. Any hints or pointers would be greatly appreciated. I think the files crtbegin.o and crtend.o are Linux-specific or maybe GNU-binutils-specific. Different platforms tend to have different strange requirements for C++ code. Loading shared libraries that happen to be written in C++ into GHCi shouldn't be a problem (or is it? definitely works on Mac OS X). Loading C++ .o files is a different story. Generally speaking, there are at least two things that set C++ .o files apart from normal C .o files: *) static constructors/destructors Sometimes there are pieces of code that expect to be called before main() or at program termination. The GHCi Linker doesn't support this, so some code may crash because things haven't been initialised properly. *) multiple definitions There is often some code in C++ header files (e.g. templates, inline functions, class members declared in the class declaration). These pieces of code are sometimes inlined, but sometimes they are not; in that case, gcc generates code for them in every .o file that uses them and counts on the linker to just include one version in the final executable. The GHCi linker will probably just abort and complain about multiply-defined symbols. The above is just theory, there might be even more problems in practice :-( . I've written a binding to a C++ library where I use a simple wrapper file to overcome the name mangling (extern C functions calling C++, nothing fancy). Is there a way to make that more GHCi friendly or should I explore other options? -- Friendly, Lemmih ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and C++.
I've written a binding to a C++ library where I use a simple wrapper file to overcome the name mangling (extern C functions calling C++, nothing fancy). Is there a way to make that more GHCi friendly or should I explore other options? What exactly is going wrong? Try wrapping your binding in a .so, that should hide all the C++ stuff from GHCi. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: hyperlinks in Haddock docs
Simon Marlow wrote: They don't look too bad to me... a bit far to the right, perhaps, but not too bad. Perhaps some lines in that table would help, or alternating grey/white background for the rows? [...] What I mean with drunk can be seen here: https://aedion.de/haskell/haddock.png It's slightly different for Firefox, Netscape,... but always wrong, mixing CSS and tables is a really dark corner. Anyway, alternating colors could be a good idea, too. Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi and C++.
Wolfgang Thaller wrote: [...] *) static constructors/destructors Sometimes there are pieces of code that expect to be called before main() or at program termination. The GHCi Linker doesn't support this, so some code may crash because things haven't been initialised properly. This will definitely be a source of trouble if you use any C++ library whatsoever. I don't know the story for Linux, but at least one other platform I know has the addresses of those constructors/destructors in special ELF sections. GHCi could easily iterate through these, but this is really highly platform-specific. There used to be a description of a widespread C++ ABI on codesourcery.com, but I can't find it anymore... :-( *) multiple definitions There is often some code in C++ header files (e.g. templates, inline functions, class members declared in the class declaration). These pieces of code are sometimes inlined, but sometimes they are not; in that case, gcc generates code for them in every .o file that uses them and counts on the linker to just include one version in the final executable. The GHCi linker will probably just abort and complain about multiply-defined symbols. IIRC, g++ uses weak symbols for this, at least on some platforms. Handling these doesn't sound too hard (easy sentence when one doesn't intend to implement it :-). The above is just theory, there might be even more problems in practice :-( . Exception handling comes to my mind. Nowadays it's often done via stack unwinding, but I don't know about the details anymore. This might cause some trouble when C++ code is called from Haskell. The only golden rule I know about this all: Use only a single C++ compiler for the compilation *and* linking of all your libraries and programs, otherwise be prepared for long hours in front of gdb... :-( Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available (breakage on x86-64)
bstrand: Simon Marlow wrote: Just to let you know, there are a number of open bug reports for GHC on the x86_64 platform, which seem to indicate some kind of occasional memory/GC problem. I'm probably not going to be able to track this down until after the 6.4 release, but we'll put out a patch as soon as we have one. Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders' Debian x86-64 ghc, although it doesn't look like a memory/GC problem to my untrained eye: ==fptools== make boot - --no-print-directory -r; in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat ../../../glafp-utils/mkdependC/mkdependC -f .depend-I../../includes -- -O-- cbits/directory.c cbits/rawSystem.c /usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs ghc: 15653112 bytes, 5 GCs, 73168/73168 avg/max bytes residency (1 samples), 63M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (5.14 elapsed), 0.03 GC (0.57 elapsed) :ghc make all rm -f System/Directory/Internals.o; if [ ! -d System/Directory/Internals_split ]; then mkdir System/Directory/Internals_split; else /usr/bin/find System/Directory/Internals_split -name '*.o' -print | xargs rm -f __rm_food; fi; /usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs-c System/Directory/Internals.hs-o System/Directory/Internals.o -ohi System/Directory/Internals.hi warning: don't know how to split object files on this architecture ghc: 76094368 bytes, 11 GCs, 2187736/4575048 avg/max bytes residency (3 samples), 66M in use, 0.00 INIT (0.00 elapsed), 0.87 MUT (13.77 elapsed), 0.14 GC (1.40 elapsed) :ghc ( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script; echo INPUT( *.o ) ld.script; /usr/bin/ld -r -x -o ../Internals.old.script; ); /usr/bin/ld:ld.script: file format not recognized; treating as linker script /usr/bin/ld:ld.script:1: syntax error make[4]: *** [System/Directory/Internals.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc' make: *** [build] Error 1 Can you try building with SplitObjs=NO ? Wolfgang, Ryan - that looks like a splitter problem, no? (The splitter is more of a dark art than the evil mangler, I propose we name it the diabolical splitter from now on.) -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
x86_64 port
Sorry if this is a RTFM type question - but what is the status of the x86_64 port? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
build failure
I've followed the instructions for building on the host for an unregistered x86_64 build, but when I do: cd glafp-utils/ make boot make I get: ... ls/Outputable.lhs utils/Panic.lhs utils/Pretty.lhs utils/PrimPacked.lhs utils/StringBuffer.lhs utils/UnicodeUtil.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs ghc-6.4.20050224: Can't find codeGen/ClosureInfo.lhs-boot (imported from absCSyn/AbsCSyn.lhs) ghc: 153327128 bytes, 67 GCs, 2285585/5010648 avg/max bytes residency (4 samples), 20M in use, 0.00 INIT (0.00 elapsed), 0.36 MUT (4.42 elapsed), 0.13 GC (0.14 elapsed) :ghc make[2]: *** [depend] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/u/kmacy/src/ghc-6.2.2/ghc' make: *** [build] Error 1 [1] + Done cd glafp-utils/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
kip.macy: Sorry if this is a RTFM type question - but what is the status of the x86_64 port? As it says on http://www.haskell.org/ghc/docs/latest/html/building/sec-port-info.html it currently works unregisterised (and is available in binary form on a number of platforms). The registerised port is being held up as none of the developers have regular access to such a machine. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: build failure
kip.macy: I've followed the instructions for building on the host for an unregistered x86_64 build, but when I do: cd glafp-utils/ make boot make I get: ... ls/Outputable.lhs utils/Panic.lhs utils/Pretty.lhs utils/PrimPacked.lhs utils/StringBuffer.lhs utils/UnicodeUtil.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs ghc-6.4.20050224: Can't find codeGen/ClosureInfo.lhs-boot (imported from absCSyn/AbsCSyn.lhs) ghc: 153327128 bytes, 67 GCs, 2285585/5010648 avg/max bytes residency (4 samples), 20M in use, 0.00 INIT (0.00 elapsed), 0.36 MUT (4.42 elapsed), 0.13 GC (0.14 elapsed) :ghc make[2]: *** [depend] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/u/kmacy/src/ghc-6.2.2/ghc' make: *** [build] Error 1 [1] + Done cd glafp-utils/ Hmm. Strange. I would suggest you bootstrap from 6.2.2 sources, using a 6.2.2 compiler to generate the sources (not 6.4) -- I bootstrapped an x86_64 box last week in this fashion. All you are really doing is trying to build 6.2.2 using 6.4, on a supported host, which should work (though there maybe some 6.4-ish reason that this is not the case). -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
number of platforms). The registerised port is being held up as none of the developers have regular access to such a machine. I'm new to Haskell but not to assembler - is the work required something that someone in my position could contribute to? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64 port
kip.macy: number of platforms). The registerised port is being held up as none of the developers have regular access to such a machine. I'm new to Haskell but not to assembler - is the work required something that someone in my position could contribute to? Certainly. Not much Haskell is required at all, and only some assembler. The porting guide contains a list of what needs to be done: http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html Much of this is done already. Simon Marlow's done the register mapping (ghc/includes/MachRegs.h) and done other registerisation work. There was a bug in gcc-3.3x that halted things for a while, but this has been fixed in 6.4 Most stuff can be figured out by looking at the code for other archs already in the relevant files. The FFI for example just requires a few dozen lines of assembly. If you felt up to it, it would be a good way to learn about ghc internals. Feel free to ask questions on the mailing list, we'll help as much as possible. Cheers, Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available (breakage on x86-64)
[...] warning: don't know how to split object files on this architecture [...] Wolfgang, Ryan - that looks like a splitter problem, no? Definitely. Looks like there is no splitter for x86-64. SplitObjs=NO is definitely required. (The splitter is more of a dark art than the evil mangler, I propose we name it the diabolical splitter from now on.) Hmmm, even 'diabolical' doesn't quite seem to capture it. While the Evil Mangler is Evil, it is not Entirely Evil. We have to ask ourselves, what would the world be like without the Evil Mangler? Can there be Good without Evil? Would the Noble Code Generator (NCG) still be Noble if there were no Evil Mangler? The Evil Mangler is the kind of Evil that still has honor. Years after the forces of Good have finally prevailed, the broken remains of the Evil Mangler will still be proudly displayed in the castle's repositories, and the descendants of the Knights who overcame It will utter Its name with respect for an honoured adversary. The Satanic Splitter however, or whatever that Nameless Nemesis should be called, is an enemy of a different kind. Instead of attacking directly and honestly, it relies on treachery to destroy its foes. It lurks in the shadow of its big brother, the Evil Mangler, and it seeks to make the unsuspecting world believe that it is relatively benign. It does nothing that is essential to The Cause, and it tells its unsuspecting victims that can say SplitObjs=NO at any time, but when they do, it punishes them with multi-megabyte executables. And it cannot even do its evil deeds by itself - without the help of a Traitor in the code generator who puts split markers into the Code, the Splitter would be helpless. And I'm quite convinced that the Splitter's agents infiltrated Apple to make sure that the dead-stripping code in Apple's linker runs really slow. If Apple's code was efficient, the Splitter would already be banished from the Land of Apples. So go ahead and call the Splitter any bad names you like :-). Cheers, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
