- Glasgow-haskell-users

Re: link problem under macosx
by John Lato 04 Nov '10

04 Nov '10

> > From: Simon Michael <simon(a)joyful.com> > > On 11/2/10 10:20 AM, John Lato wrote: > > Since Apple seems disinclined to fix the system's libiconv, and macports > projects refuse to use it, the only real > > solution is to use either HP without macports or the macports GHC without > HP. Personally I chose to use the HP and > > Not so, as mentioned you just need to make sure /usr/lib is in the link > path before /opt/local/lib. Add -L/usr/lib to > your build flags for ghc --make, and put: > > extra-lib-dirs: /usr/lib > extra-lib-dirs: /opt/local/lib > > in that order in ~/.cabal/config for cabal build. > > This is a very FAQ and needs to be documented somewhere more obvious, I > wonder where. cabal-install and GHC release notes ? > As I mentioned in another reply, this worked for me until I tried to link to a macports lib (I think some regex lib) that actually used the macports libiconv (a lot of them don't even if they pull in the dependency). Then I was really stuck because I had dependencies on two different libiconv's, and neither one would link properly. As such, I consider this a pretty fragile "solution". John

2 1

MonoLocalBinds and darcs
by Sittampalam, Ganesh 04 Nov '10

04 Nov '10

Hi, I've just been updating darcs 2.5 for GHC 7.0. I had to add about 40 signatures for MonoLocalBinds in about 140 files/30K LOC. Is that about normal? darcs does make fairly heavy use of rank 2 polymorphism which leads to quite a lot of local definitions needing to be polymorphic. Also, NoMonoLocalBinds didn't help at all, which surprised me a bit - I thought it might at least make some of the signatures unnecessary. Finally, is NoMonoLocalBinds supposed to imply NPlusKPatterns? The only changes I was able to revert when I enabled it were a couple of those! Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

6 7

Re: [Haskell-cafe] change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
by David Fox 04 Nov '10

04 Nov '10

I would love to know the answer to this. On Tue, Nov 2, 2010 at 3:36 PM, Jeremy Shaw <jeremy(a)n-heptane.com> wrote: > Hello, > > I have a module, XMLGenerator, which has some overlapping instances. > I have a second module, Test, which imports that module and also adds > some more overlapping instances. > > Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top. > > Under some old version of 6.13 (and probably 6.12), if I put both > modules in the same directory and try to load Test.hs, it gets the > error: > > Test.hs:16:15: > Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m)) > arising from a use of `asChild' at Test.hs:16:15-21 > Matching instances: > instance (m1 ~ m, EmbedAsChild m c) => > EmbedAsChild m (XMLGenT m1 c) > -- Defined at XMLGenerator.hs:16:10-68 > instance (XML m ~ x, XMLGen m) => EmbedAsChild m x > -- Defined at XMLGenerator.hs:19:10-51 > In the first argument of `($)', namely `asChild' > In the expression: asChild $ (genElement "foo") > In the definition of `asChild': > asChild b = asChild $ (genElement "foo") > > If I put the XMLGenerator module in a separate package, dummy-hsx, and > the Test modules links against it, I still get the error. > > *but* if I add: > > Extensions: OverlappingInstances > > to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for > starters, I do not understand why that happens. > > Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I > always get the error: > > Test.hs:16:15: > Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m)) > arising from a use of `asChild' > Matching instances: > instance [overlap ok] (m1 ~ m, EmbedAsChild m c) => > EmbedAsChild m (XMLGenT m1 c) > -- Defined in XMLGenerator > (The choice depends on the instantiation of `m' > To pick the first instance above, use -XIncoherentInstances > when compiling the other instance declarations) > > Adding the IncoherentInstances flag does make it compile -- but I have > never enabled that flag and not regretted it. > > What changed between GHC 6.12 and GHC 7.0? Is there a some solution > besides using IncoherentInstances in every module that imports > XMLGenerator? > > I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal. > > thanks! > - jeremy > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Fixing LDAP lib compilation on OpenBSD
by Julien Dessaux 04 Nov '10

04 Nov '10

Hi GHC folks, I'm using the LDAP lib for one of my projects and I found a problem while building it on an OpenBSD system. It wouldn't compile because there is a macro named differently in the ldap.h include file. Under linux, this macro is named LDAP_X_PROXY_AUTHZ_FAILURE but on OpenBSD (and probably other BSD flavours), it's named LDAP_PROXY_AUTHZ_FAILURE. I attached the diff I wrote in order to compile the lib on OpenBSD, but it's not a patch I can submit cause it now won't compile on Linux. How can I amend this in order to have a code that would compile on both systems? How is it possible to specify such conditional system dependent stuff for a C binding? Thanks in advance for your help, -- Julien Dessaux

2 3

generating C stubs with GHC API
by Victor Nazarov 03 Nov '10

03 Nov '10

I would like to get access to functions exported from Haskell module and to generate custom stubs for them using GHC API. As I understand, I need to obtain a list of ForeignDecl's (data structure defined in HsDecls GHC module) for given source module. How to achieve this with GHC API? -- Victor Nazarov

1 0

link problem under macosx
by Christian Maeder 03 Nov '10

03 Nov '10

Hi, after installing http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386… and various more libraries using cabal, we get the following linker error below. A simple hello program compiles and links fine and uses /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) as shown by "otool -L". Does someone have an explanation or solution? Cheers Christian Linking dist/build/hets/hets ... Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status

3 4

making 7.01-pre
by Serge D. Mechveliani 03 Nov '10

03 Nov '10

Dear GHC developers, I am testing this fresh ghc-7.0.0.20101028 on Debian Linux, i386-family. Making it from source by ghc-6.12.3 is all right. Then, making it from source by itself reports (here I abbreviate the messages by inserting `...') --------------------------------------------------------------------- + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old ... ... "inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp//. "inplace/bin/mkdirhier" bootstrapping/. "/home/mechvel/ghc/7.01pre/inst1/bin/ghc" -H32m -O --make utils/ghc-cabal/ghc-cabal.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal ... ... "rm" -f compiler/stage1/ghc_boot_platform.h Creating compiler/stage1/ghc_boot_platform.h... Done. "/usr/bin/gcc" -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Irts -DGEN_HASKELL -c includes/mkDerivedConstants.c -o includes/dist-ghcconstants/build/mkDerivedConstants.o ... ... ... utils/genprimopcode/dist/build/Lexer.o: In function `s2yT_info': (.text+0x1e1d): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' ... ... utils/genprimopcode/dist/build/Parser.o: In function `s4pK_info': (.text+0x5691): undefined reference to `__stginit_arrayzm0zi3zi0zi2_DataziArray_' collect2: ld returned 1 exit status make[1]: *** [utils/genprimopcode/dist/build/tmp/genprimopcode] Error 1 make: *** [all] Error 2 --------------------------------------------------------------------- Why cannot it make itself? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

4 4

Re: link problem under macosx
by John Lato 03 Nov '10

03 Nov '10

> > From: Christian Maeder <Christian.Maeder(a)dfki.de> > > Am 02.11.2010 11:48, schrieb Christian Maeder: > > Hi, > > > > after installing > > > http://lambda.galois.com/hp-tmp/2010.2.0.0/haskell-platform-2010.2.0.0.i386… > > and various more libraries using cabal, we get the following linker > > error below. > > > > A simple hello program compiles and links fine and uses > > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version > > 7.0.0) as shown by "otool -L". > > > > Does someone have an explanation or solution? > > adding "-L/usr/lib" as first argument to ghc solved the problem. > Another cabal-package (gtk and friends) used /opt/local/lib under > library-dirs:. > > Are there better workarounds? > Judging from the /opt/*, it looks like you're using macports for gtk. The libiconv provided by macports is incompatible with the system libiconv, and trying to mix the two is a doomed effort. If you're using a gtk2hs from macports (or gtk+ from macports) it will link to /opt/local/lib/libiconv, but HP and ghc core libraries will link to /usr/lib/libiconv. This means that various haskell packages will be entirely incompatible with each other, and problems will manifest as these linker errors. Since Apple seems disinclined to fix the system's libiconv, and macports projects refuse to use it, the only real solution is to use either HP without macports or the macports GHC without HP. Personally I chose to use the HP and built gtk+ using http://gtk-osx.sourceforge.net/ , which is moderately painful but has been stable once it's built. John

2 1

Local evidence and type class instances
by Max Bolingbroke 02 Nov '10

02 Nov '10

Hi GHC users, Now that the Glorious New type checker can handle local evidence seamlessly, is it a big implementation burden to extend it to deal with local *type class instances* in addition to local *equality constraints*? For example, you could write this: """ f :: Bool f = id < id where instance Ord (a -> b) where _ `compare` _ = LT """ Not only would this prevent instances from "leaking" into all importing modules, but you could refer to *lexically scoped variables* in the type class instance. This would let programmers implement e.g. implicit configurations in the style of Kieslyov and Shan (http://okmij.org/ftp/Haskell/types.html#Prepose) without any mad hackery to tunnel pointers through the type system. Of course, it could lead to problems. For example: """ newtype MyInt = MyInt { unMyInt :: Int } f :: [Int] -> S.Set Int f xs = S.map unMyInt $ S.toList (map MyInt xs) where instance Ord MyInt where x `compare` y = unMyInt x `compare` unMyInt y g :: [Int] -> S.Set Int g xs = S.map unMyInt $ S.toList (map MyInt xs) where instance Ord MyInt where x `compare` y = unMyInt y `compare` unMyInt x main = do let s1 = f [1, 2] s2 = g [1, 2] print $ s1 == s2 -- prints False! print $ S.toList s1 == s2 -- prints True! """ I don't think this is a big problem. It would be up to the users of this extension to do the Right Thing. As Kieslyov and Shan point out, this extension also kills the principal types property - but so do GADTs. Just add more type signatures! Are there big theoretical problems with this extension, or is it just a lack of engineering effort that has prevented its implementation? Max

4 3

GHC.Types consturctors with #
by Larry Evans 01 Nov '10

01 Nov '10

http://www.haskell.org/ghc/docs/6.10.2/html/libraries/ghc-prim/GHC-Types.ht… contains: data Int = I# Int# What does I# Int# mean? I've tried a simple interpretation: Prelude GHC.Types> I# 5# <interactive>:1:5: parse error (possibly incorrect indentation) Prelude GHC.Types> but obviously that failed :( TIA. -Larry

3 2