- Glasgow-haskell-users

GHC 6.8.1 and HDirect
by Fernand 21 Nov '07

21 Nov '07

Hi dear fellow ghc users, I simply wanted to let people know that I apparently succeeded in compiling a patched version of HDirect with GHC 6.8.1 (with typelibs support). At least, I could compile some of the examples and had very simple test programs launch/connect to Word and Excel using automation. I lack time to really clean up the library (I did not made any Cabal patch and currently directly link with the « .a » and « .o » of the various modules), but feel free to contact me if you need some help to use hdirect with GHC 6.8.1. Sincerely yours, sL

1 0

ghc 6.8.1 windows link issue ?
by Fernand 21 Nov '07

21 Nov '07

Dear all, Giving a try to GHC 6.8.1 under Windows, I stumble upon the following issue (yes, I'm struggling with HDirect), which did not occur with the 6.6 version : the linking phase of my project fails with $ C:/ghc/ghc-6.8.1/bin/ghc -o ihc.exe -fglasgow-exts -static -fvia-C -Rghc-timing -Wall -recomp AbsHUtils.o AbstractH.o Attribute.o Bag.o [... lots of files, among which we have CoreUtils.o ...] CoreUtils.o(.text+0x15066):ghc2436_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' CoreUtils.o(.text+0x150b0):ghc2436_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' CoreUtils.o(.text+0x1ac23):ghc2436_0.hc: undefined reference to `__stginit_containerszm0zi1zi0zi0_DataziGraph_' IDLUtils.o(.text+0x6026):ghc768_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' IDLUtils.o(.text+0x6070):ghc768_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' IDLUtils.o(.text+0xc607):ghc768_0.hc: undefined reference to `__stginit_containerszm0zi1zi0zi0_DataziGraph_' collect2: ld returned 1 exit status Indeed, that symbol is undefined in the CoreUtils file : $ nm CoreUtils.o | grep strongl U _containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure As far as I understand, this is a reference to the Data.Graph function stronglyConnComp (which can be seen in the « containers-0.1.0.0/Data/Graph.hi » interface file ; according to the haddock documentation of GHC, that function is indeed in the Data.Graph module, which is imported by the CoreUtils.lhs file). What is strange to me is that $ nm libHSghc.a | grep strongl gives : 00000598 D _ghczm6zi8zi1_Digraph_stronglyConnComp_closure which could explain why that function is not found. May be I'm looking at the wrong file, I don't know much of the linking and name-mangling process at hand here (Digraph vs. DataziGraph ?). What I do not understand is what causes that issue, which seems to only concern the Data.Graph module so far. Hopes this makes sense to you, Sincerely yours, Samuel

2 3

Re: [Haskell] recursive deriving
by Duncan Coutts 21 Nov '07

21 Nov '07

On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote: > When you want automated deriving of show/read etc., you need all the > components of your type also to be instances of show/read but you won't > want to *require* them to be automatically generated verions. > > Standalone deriving does the wrong thing here. Standalone deriving > should not cause an overlapping instance error if someone derives an > instance manually. Instead, the manually derived instance should be > treated as more specific and win out. > > The other part of this problem is that you can't do automatic recursive > deriving and this results in a ridiculous amount of boilerplate. I know > some people have a theory that they want to avoid accidentally creating > instances for things that shouldn't have them, but the solution to that > is probably to add some declaration for types that prohibits automatic > deriving for those types. The 99% case is that automatic deriving is ok. > > Proposed syntax: > > derive instance Show T recursively > data T = T no-deriving (Ord,Eq) I would expect that if the data constructor for T is not exported then standalone deriving should not work. However this appears not to be the case which breaks module abstraction. Foo.hs: module Foo ( T, t ) where data T = T t = T Bar.hs: import Foo deriving instance Eq T $ ghci Bar.hs -XStandaloneDeriving [1 of 2] Compiling Bar ( Bar.hs, interpreted ) [2 of 2] Compiling Main ( Baz.hs, interpreted ) Ok, modules loaded: Bar, Main. *Main> t == t True You could write that Eq instance by hand since they do not have access to the T constructor, then StandaloneDeriving should not be able to so either. I think it's a design flaw in standalone deriving. Does anyone else agree? Should we file a bug report? Duncan

3 2

Exposed module still hidden, why?
by Greg Fitzgerald 21 Nov '07

21 Nov '07

Using GHC 6.8.1 on Windows XP, after having used ghc-pkg to expose ' directory-1.0.0.0', I am getting an error when I build haddock that says the package is hidden. When I type "ghc-pkg list", the package is not in parenthesis. Typing "ghc -v" says that it is using the file from "C:\ghc\ghc-6.8.1\package.conf". That package.conf file has the 'exposed' set to True for that file. Why does GHC still think the package is hidden? ...\haddock-0.8>runhaskell Setup.lhs configure Configuring haddock-0.8... ...\haddock-0.8>runhaskell Setup.lhs build Preprocessing executables for haddock-0.8... shift/reduce conflicts: 5 Building haddock-0.8... src/Main.hs:49:7: Could not find module `System.Directory': it is a member of package directory-1.0.0.0, which is hidden ...\haddock-0.8>ghc-pkg list C:/ghc/ghc-6.8.1\package.conf: Cabal-1.2.2.0, HUnit-1.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, Win32-2.1.0.0, array-0.1.0.0, base-3.0.0.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.0, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.1), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.1, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, xhtml-3000.0.2.1 Thanks, Greg

4 3

ANNOUNCE: Important bug fix for regex-pcre ByteStrings.
by ChrisK 20 Nov '07

20 Nov '07

Greetings, There are new version 0.82 and 0.93 of regex-posix. If you use regex-posix with Data.ByteString then you should upgrade to obtain a fix for a crash error. There are new version of regex-pcre available on hackage and the two darcs repositories: http://darcs.haskell.org/packages/regex-pcre/ for "stable" version 0.82 and http://darcs.haskell.org/packages/regex-unstable/regex-pcre/ for "unstable" version 0.93 The new version regex-pcre-0.82 replaces the broken version 0.81 The new version regex-pcre-0.93 replaces the broken version 0.92 I apologize for the error. I took the address of the ByteString to give to the pcre library by using unsafeUseAsCStringLen. I had not appreciated that this can return a null pointer for an empty ByteString. My code caught this null pointer and reported it, however, and so a good error message sent in by a user allowed me to quickly find and hopefully fix it. For version 0.92 the error also applied to Lazy ByteStrings. In case anyone is curious, the fixed code checks the pointer returned by unsafeUseAsCStringLen and replaces a null pointer to a non-null pointer to a private private bytestring "myEmpty" with the length set to 0 by "trim": > {-# INLINE asCStringLen #-} > asCStringLen :: ByteString -> (CStringLen -> IO a) -> IO a > asCStringLen s op = B.unsafeUseAsCStringLen s checked > where checked cs@(ptr,_) | ptr == nullPtr = B.unsafeUseAsCStringLen myEmpty (op . trim) > | otherwise = op cs > myEmpty = B.pack [0] > trim (ptr,_) = (ptr,0) This fix is motivated by desiring to ensure asCStringLen never passes a null pointer to "op" and that no memory copy operations are used. The safe "useAsCString(Len)" do not appear capable of returning a null pointer. Only "unsafeUseAsCString(Len)" on an empty bytestring might return a null pointer. -- Chris

1 0

The order if bindings generated by GHC
by Victor Nazarov 19 Nov '07

19 Nov '07

I use STG-bindings generated by GHC during CoreToSTG phase. What is the order of this bindings is it random or does it correspond to original source code or does it reflect the dependency structure of the program? If I define the following in my program: data Numeral = Zero | Succ Numeral zero = Zero one = Succ zero ... ten = Succ nine the order of zero .. ten definition will remain the same, but the special Zero binding will be generated and added to the end of the bindings list. But Zero is used by binding of one (strangely enough) so order doesn't reflect dependency. What is the order of bindings? If I need the order reflecting dependency, should I sort it myself by SRT tables or there is an easier way? -- vir http://vir.comtv.ru/

3 4

The order if bindings generated by GHC
by Victor Nazarov 19 Nov '07

19 Nov '07

> ==================== STG syntax: ==================== > Foo.zero = NO_CCS Foo.Zero! []; > SRT(Foo.zero): [] > Foo.one = NO_CCS Foo.Succ! [Foo.Zero]; > SRT(Foo.one): [] > Foo.ten = NO_CCS Foo.Succ! [Foo.one]; > SRT(Foo.ten): [] > Foo.Zero = NO_CCS Foo.Zero! []; > SRT(Foo.Zero): [] > Foo.Succ = \r [eta_s68] Foo.Succ [eta_s68]; > SRT(Foo.Succ): [] > In this output the dependecy is as follows: Foo.zero `depends_on` [] Foo.one `depends_on` [Foo.Zero] -- this is the source of my question Foo.ten `depends_on` [Foo.one] Foo.Zero `depends_on` [] Foo.Succ `depends_on` [] Foo.one here saves the Foo.Zero as an argument of constructor application, i. e. saves Foo.Zero's address in one of the allocated closure's field. So I think Foo.Zero must be defined before Foo.one. -- vir http://vir.comtv.ru/

1 0

GHC 6.8.1 on powerpc OS X 10.5
by Chris Kuklewicz 19 Nov '07

19 Nov '07

So I decided to try and route around the ld/collect2 problems with ghc-6.8.1 not working on powerpc OS X 10.5 OS X 10.5 (Leopard) uses XCode 3.0 which has a gcc-4.0 toolchain. So I try to get another gcc & binutils from macports. This failed. All of gcc40 gcc41 gcc42 and gcc43 failed to compile successfully with macports. So I switched to trying fink, which offers gcc-4.2.2 and this did compile and install. Hooray. Unfortunately, using ghc-6.6.1 (from when I ran OS 10.4 Tiger) with gcc-4.2.2 does not work when compiling ghc-6.8.1 (at least on this platform). > ------------------------------------------------------------------------ > == make boot -r; > in /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1/compiler > ------------------------------------------------------------------------ > ../utils/mkdirhier/mkdirhier stage1 > for i in utils basicTypes types hsSyn prelude rename typecheck deSugar coreSyn vectorise specialise simplCore stranal stgSyn simplStg codeGen main profiling parser cprAnalysis ndpFlatten iface cmm nativeGen; do \ > ../utils/mkdirhier/mkdirhier stage1/$i; \ > done > Creating stage1/ghc_boot_platform.h... > Done. > ../utils/genprimopcode/genprimopcode --primop-tag < prelude/primops.txt > primop-tag.hs-incl > /bin/sh: line 1: 59384 Illegal instruction ../utils/genprimopcode/genprimopcode --primop-tag < prelude/primops.txt > primop-tag.hs-incl > make[1]: *** [primop-tag.hs-incl] Error 132 > make[1]: *** Deleting file `primop-tag.hs-incl' > make: *** [stage1] Error 1 Running "../utils/genprimopcode/genprimopcode --primop-tag" produces "Illegal instruction" There were other odd messages during the make,such as in this early output: > ------------------------------------------------------------------------ > == make boot -r; > in /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1/compat > ------------------------------------------------------------------------ > ../utils/mkdependC/mkdependC -f .depend -I. -Iinclude -I../includes -- -O -I. -Iinclude -D__GHC_PATCHLEVEL__=1 -I../libraries/base/cbits -I../libraries/base/include -- cbits/directory.c cbits/rawSystem.c cbits/unicode.c > /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Compat/Unicode.hs Distribution/Compat/Directory.hs Distribution/Compat/Exception.hs Distribution/Compat/Map.hs Distribution/Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Compat/TempFile.hs Distribution/Compiler.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Simple/Program.hs Distribution/Simple/Utils.hs Distribution/System.hs Distribution/Verbosity.hs Distribution/Version.hs Language/Haskell/Extension.hs System/FilePath.hs System/FilePath/Posix.hs System/FilePath/Windows.hs Trace/Hpc/Mix.hs Trace/Hpc/Tix.hs Trace/Hpc/Util.hs > <<ghc: 36490248 bytes, 5 GCs, 130248/130248 avg/max bytes residency (1 samples), 16M in use, 0.01 INIT (0.01 elapsed), 0.22 MUT (4.47 elapsed), 0.06 GC (0.43 elapsed) :ghc>> > make all > /usr/local/bin/ghc -H16m -O -w -I. -Iinclude -Rghc-timing -ignore-package Cabal -ignore-package filepath -I../libraries -fglasgow-exts -no-recomp -c System/FilePath/Posix.hs -o System/FilePath/Posix.o -ohi System/FilePath/Posix.hi > gcc: unrecognized option '-no-cpp-precomp' > > /var/folders/CT/CTQA-fMz2RWZwk+BYmhr7U++-Eg/-Tmp-//ghc64877_0/ghc64877_0.s:6606:0: > section difference relocatable subtraction expression, "_s2tx_0_alt" minus "_s2tx_info" using a symbol at the end of section will not produce an assembly time constant > > /var/folders/CT/CTQA-fMz2RWZwk+BYmhr7U++-Eg/-Tmp-//ghc64877_0/ghc64877_0.s:6606:0: > use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = _s2tx_0_alt - _s2tx_info The '-no-cpp-precomp' and 'section difference ...' and 'use a symbol ...' messages repeat often. I looked at trac, and can only find the closed ticket http://hackage.haskell.org/trac/ghc/ticket/1427 relating to gcc-4.2 issues. Does anyone have suggestions? hints? bad jokes? -- Chris K

5 8

GHC 6.8.1 on Mac OS X 10.4 (Tiger)
by Christian Maeder 17 Nov '07

17 Nov '07

Dear Intel Mac Users, I've also created a binary distribution of GHC 6.8.1 for Mac OS X 10.4 (Tiger) that is based on gmp3 and readline5 libraries under /opt/local/ (without framework dependencies). You can set the DYLD_LIBRARY_PATH if your gmp3 and readline5 libraries are elsewhere. http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… Christian I wonder if that distribution would run under Leopard, too.

2 1

ghc trac wiki, rss feeds not activated?
by Claus Reinke 17 Nov '07

17 Nov '07

a lot of ghc-related discussion takes place on ghc's trac wiki these days, as does the development of ghc docs. so i'd like to follow wiki changes as an rss feed. this is supported, according to http://hackage.haskell.org/trac/ghc/wiki/TracRss http://hackage.haskell.org/trac/ghc/wiki/TracTimeline unfortunately, i haven't seen that xml/rss icon on any ghc trac wiki page, and the url modifier is not otherwise documented, either. is that an optional feature that hasn't been activated? could rss feeds for the ghc trac wiki please be made available? claus

2 2